mam usługę, która trwa jakiś podmiot i musi zapisać/uaktualnić ten podmiot:Usługa RESTful, jak odpowiedzieć, jeśli sprawdzanie poprawności nie powiodło się?
http://myhost.com/rest/entity
używam POST i przedkłada JSON. Usługa wewnętrzna wykrywa, że przekazana jednostka nie jest dobra. Nieważne, zamówienie przekazane do klienta, które nie istnieje, itp.
Jak mam odpowiedzieć? HttpCode.NotFound? Lub inni? Jak odpowiadasz na takie rzeczy?
W naszym projekcie w takich sytuacjach należy wykonać następujące czynności:
{"message":"%extended error message here%"}Ale to naprawdę bardzo subiektywny.
Polecam również czytanie This blog article on RESTfull error handling - opisuje wiele dostępnych opcji, dzięki czemu można wybrać coś dla siebie.
Oto, co robimy. Zwracamy ten sam żądany typ mediów, jeśli jest dostępny. W świecie WWW otrzymasz 400 znaków z tekstem \ html. W tym przykładzie typem nośnika jest aplikacja \ json – suing
Dziękujemy! Zastanawiałem się nad przekazaniem nagłówka informacji w uzupełnieniu do kodu statusu, ale między artykułem, który poleciłeś, a tym stanowiskiem, myślę, że zdecyduję się na wspólny obiekt odpowiedzi dla moich usług i użyję tylko kodów 400 i 200 (Inne niż 401 dla auth) – katit
Myślę, że powinieneś wybrać client error code. 400 Bad Request lub 403 Forbidden może być dobry początek
418 jest oczywistym wyborem. –
403 nie jest odpowiedni dla opisanego scenariusza. –
Dlaczego 403 nie jest odpowiedni? http://stackoverflow.com/a/3290369/59639 Wygląda na to, że istnieją różne szkoły na 400 vs. 403 –
422 Unprocessable Entity, defined in WebDAV (RFC 4918):
422 (niedające się przetwarzać Entity) kod stanu oznacza, że serwer rozumie typ zawartości podmiotu żądanie (stąd 415 (Kod stanu nieobsługiwanego nośnika) jest niewłaściwy), a składnia encji żądania jest poprawna (dlatego kod statusu 400 (nieprawidłowe żądanie) jest niewłaściwy), ale nie mógł przetworzyć zawartych instrukcji. Na przykład ten warunek błędu może wystąpić, jeśli treść żądania XML zawiera poprawnie sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.
Naprawdę to lubię. Prawdopodobnie nie będzie to popularne wśród purystów, ale jest o wiele lepiej, gdy używa tego samego statusu, co źle sformułowana prośba. –
W projekcie, nad którym pracuję, bardzo niepokoiła mnie również niezdolność klienta do rozróżniania błędów walidacji i nieprawidłowych próśb od samego kodu statusu (bez inspekcji treści odpowiedzi) i niezależnie myślę o użyciu 422 do rozróżnienia były. Natknąłem się na to, robiąc pewne testy sprawdzające poprawność, aby upewnić się, że nie ma lepszych alternatyw, więc cieszę się, że inni ludzie zastosowali to podejście i że nie jest to całkowicie poza polem.Czy mogę przypuszczać, że żadne z was nie spotkało się z podobnymi problemami z tym podejściem? – rscarter
Cóż, to naprawdę zależy od Ciebie, to twoja usługa. – jgroenen
możliwy duplikat [kodów statusu HTTP REST dla nieudanego sprawdzania poprawności lub nieprawidłowego duplikatu] (http://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation- or-invalid-duplicate) – MaxiWheat