Kod statusu HTTP do aktualizacji i usunięcia?


Odpowiedzi:


2099

W przypadku żądania PUT : HTTP 200 lub HTTP 204 powinny oznaczać „pomyślne zaktualizowanie zasobu”.

W przypadku żądania DELETE : HTTP 200 lub HTTP 204 powinno oznaczać „zasób usunięty pomyślnie”. Można również zwrócić HTTP 202, co oznaczałoby, że instrukcja została zaakceptowana przez serwer i „zasób został oznaczony do usunięcia”.

POŁOŻYĆ

Jeśli istniejący zasób zostanie zmodyfikowany, KODY odpowiedzi 200 (OK) lub 204 (Brak treści)> POWINNY zostać wysłane, aby wskazać pomyślne zakończenie żądania.

USUNĄĆ

Pomyślna odpowiedź POWINNA wynosić 200 (OK), jeśli odpowiedź zawiera byt opisujący status, 202 (Zaakceptowana), jeśli akcja nie została jeszcze wykonana, lub 204 (Brak treści), jeśli akcja została podjęta, ale odpowiedź nie obejmuje jednostka.

Źródło: W3.org: Definicje metod HTTP / 1.1

HTTP 200 OK: Standardowa odpowiedź na udane żądania HTTP. Rzeczywista odpowiedź będzie zależeć od użytej metody żądania.

HTTP 204 Brak treści: Serwer pomyślnie przetworzył żądanie, ale nie zwraca żadnej treści

Źródło: Lista kodów stanu HTTP: 2xx Sukces


40
Bardzo przydatny post! Zastanawiam się jednak, jaki powinien być kod stanu HTTP, ponieważ żądanie wysłane przez klienta jest prawidłowe (USUŃ moją stronę / podmiot / 123 ), a obiekt do usunięcia nie istnieje.
Martin

64
@ Martin: W takim przypadku usługa powinna zwrócić HTTP 404. Ściśle mówiąc, żądanie DELETE lub GET dla zasobu, który nie istnieje, nie jest żądaniem „poprawnym” - tzn. klient nie powinien ponawiać próby tego żądania, ponieważ nigdy się nie powiedzie ... Protokół HTTP definiuje 2 kategorie problemów - te z kodem statusu 4xx, w których klient musi zmodyfikować żądanie przed ponowną próbą, oraz te o statusie 5xx kod wskazujący, że usługa napotkała problemy, a klient powinien / mógłby ponowić to samo dokładne żądanie bez jego zmiany.
Daniel Vassallo,

17
@JeffMartin Może tak być z punktu widzenia użytkownika, ale jeśli chodzi o serwer, jeśli zasób nie istnieje, serwer powinien zwrócić 404.
Randolpho

17
@Randolpho, w Idempotence chodzi o uzyskanie tego samego rezultatu, niezależnie od tego, czy wywołasz operację raz czy wiele razy. Klient prosi o usunięcie zasobu. Jaka jest korzyść ze zwrotu 404? Dlaczego musi wiedzieć tak czy inaczej? Teraz logika klienta musi obsługiwać dwa osobne kody odpowiedzi zamiast jednego.
Gili

26
@Gili: być może wiki wyjaśni to lepiej: Metody PUT i DELETE są zdefiniowane jako idempotentne ... zauważ, że idempotence odnosi się do stanu systemu po zakończeniu żądania, więc podczas działania serwera (np. Usunięcia rekordu ) lub zwracany kod odpowiedzi może być inny przy kolejnych żądaniach, za każdym razem stan systemu będzie taki sam.
Randolpho,

857

Krótka odpowiedź: zarówno dla PUT, jak i DELETE, powinieneś wysłać albo 200 (OK), albo 204 (Brak treści).

Długa odpowiedź: oto kompletny schemat decyzyjny (kliknij, aby powiększyć).

Schemat decyzyjny HTTP 1.1

Źródło: https://github.com/for-GET/http-decision-diagram


37
Schemat jest niesamowity. Czy jest dostępna wersja do wydruku w wyższej rozdzielczości?
KiKi

1
W kontekście testu POST istniejącego zasobu inna dyskusja SO ( stackoverflow.com/questions/3825990/... ) sugeruje wysłanie 409 konfliktu lub 302 znalezionego zamiast dołączania zawartości.
koppor

7
Jestem ciekawy, czy odpowiedzi 204 i 200 po usunięciu powinny zostać odwrócone, a jeśli są prawidłowe, dlaczego? Usunięte? -> Odpowiedź obejmuje podmiot? -> tak -> 204 Brak treści; nie -> 200 OK
mat

62
Zaktualizowana wersja obrazu znajduje się tutaj: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
zaius

19
Brakuje PATCH.
doremi

151

Oto kilka porad:

USUNĄĆ

  • 200 (jeśli chcesz wysłać dodatkowe dane w odpowiedzi) lub 204 (zalecane).

  • 202 Operacja usunięta nie została jeszcze zatwierdzona.

  • Jeśli nie ma nic do usunięcia, użyj 204 lub 404 (operacja DELETE jest idempotentna, usunięcie już usuniętego elementu jest udana , więc możesz zwrócić 204 , ale prawdą jest, że idempotent niekoniecznie oznacza tę samą odpowiedź)

Inne błędy:

  • 400 Złe żądanie (źle sformułowana składnia lub złe zapytanie jest dziwne, ale możliwe).
  • 401 Błąd nieautoryzowanego uwierzytelnienia
  • 403 Zabronione : błąd autoryzacji lub nieprawidłowy identyfikator aplikacji.
  • 405 Niedozwolone . Pewnie.
  • 409 Konflikt zasobów może być możliwy w złożonych systemach.
  • I 501 , 502 w przypadku błędów.

POŁOŻYĆ

Jeśli aktualizujesz element kolekcji

  • 200/204 z tych samych powodów, co DELETE powyżej.
  • 202, jeśli operacja nie została jeszcze zatwierdzona.

Element odniesienia nie istnieje:

  • PUT może mieć wartość 201 (jeśli element został utworzony, ponieważ takie jest Twoje zachowanie)
  • 404 Jeśli nie chcesz tworzyć elementów za pomocą PUT.

  • 400 Złe żądanie (źle sformułowana składnia lub złe zapytanie częściej niż w przypadku DELETE).

  • 401 Nieautoryzowane
  • 403 Zabronione : Błąd uwierzytelnienia lub nieprawidłowy identyfikator aplikacji.
  • 405 Niedozwolone . Pewnie.
  • 409 Konflikt zasobów może być możliwy w złożonych systemach, tak jak w USUŃ.
  • 422 Nieprzetworzona jednostka Pomaga odróżnić „niepoprawne żądanie” (np. Źle sformułowany XML / JSON) od niepoprawnych wartości pól
  • I 501 , 502 w przypadku błędów.

7
Ta odpowiedź składa się prawie w całości z dwóch dużych cytatów, ale nie ma przypisania. Skąd cytujesz?
Quentin

Czy 204 jest odpowiednim statusem do zwrócenia dla żądania PUT, jeśli stan nie zostanie skutecznie zmieniony? Na przykład poprosisz o dezaktywację użytkownika, ale użytkownik jest już nieaktywny.
Г Г И І И О

Żądanie PUT jest idempotentne, więc możesz zwrócić 204, ponieważ obiekt zmienił się w systemie. PUT nie jest PATCH, więc nie masz pewności, które pole chcesz zmienić. Możesz odesłać 501 - 502, jeśli twój projekt musi wiedzieć, czy obiekt był dokładnie taki sam jak obiekt w żądaniu, ale ... Nie podoba mi się to .. Wolę 204 lub, jeśli chcesz dezaktywuj użytkownika, nie zmieniając więcej pól, być może możesz użyć PATCH.
Alfonso Tienda

1
Dodałbym encję nieprzetworzoną HTTP 422. Pomaga odróżnić „niepoprawne żądanie” (np. Źle sformułowany XML / JSON) od niepoprawnych wartości pól.
vdboor


10

Oprócz 200 i 204, 205 (Resetuj zawartość) może być prawidłową odpowiedzią.

Serwer spełnił żądanie, a klient użytkownika POWINIEN zresetować widok dokumentu, który spowodował wysłanie żądania ... [np.] Wyczyszczenie formularza, w którym podano dane wejściowe.


6

Ponieważ pytanie zagłębia się w pytanie, czy DELETE „powinien” zwrócić 200 w porównaniu z 204 , warto wziąć pod uwagę, że niektórzy ludzie zalecają zwrócenie encji z linkami, więc preferowana jest wartość 200 .

„Zamiast zwracać 204 (bez zawartości) interfejs API powinien być pomocny i sugerować miejsca, do których należy się udać. W tym przykładzie myślę, że jednym oczywistym linkiem do podania jest„ ”gdzieś.com/container/” (minus „zasób”) ”- kontener, z którego klient właśnie usunął zasób. Być może klient chce usunąć więcej zasobów, więc byłoby to pomocne łącze ”.

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-respactions/

Jeśli klient napotka odpowiedź 204, może się poddać, przejść do punktu wejścia interfejsu API lub wrócić do poprzedniego zasobu, który odwiedził. Żadna z tych opcji nie jest szczególnie dobra.

Osobiście nie powiedziałbym, że 204 jest zły (podobnie jak autor; mówi „denerwujący”), ponieważ dobre buforowanie po stronie klienta ma wiele zalet. Najlepiej jest zachować spójność w obu kierunkach.


6

Oto kod statusu, który powinieneś znać ze względu na swoją wiedzę.

1XX Odpowiedzi na informacje

  • 100 Kontynuuj
  • 101 Protokoły przełączania
  • 102 Przetwarzanie
  • 103 Wczesne wskazówki

2XX Sukces

  • 200 OK
  • 201 Utworzono
  • 202 Zaakceptowano
  • 203 Informacje nieautorytatywne
  • 204 Brak treści
  • 205 Zresetuj zawartość
  • 206 Częściowa zawartość
  • 207 Multi-Status
  • 208 Już zgłoszono
  • Użyto 226 IM

Przekierowanie 3XX

  • 300 różnych wyborów
  • 301 Przeprowadził się na stałe
  • 302 Znaleziono
  • 303 Zobacz inne
  • 304 Nie zmodyfikowano
  • 305 Użyj proxy
  • 306 Przełącznik proxy
  • 307 Tymczasowe przekierowanie
  • 308 Stałe przekierowanie

4XX Błędy klienta

  • 400 złych wniosków
  • 401 Nieautoryzowane
  • 402 Wymagana płatność
  • 403 Zabronione
  • 404 Nie znaleziono
  • 405 Metoda niedozwolona
  • 406 Niedopuszczalne
  • 407 Wymagane uwierzytelnienie serwera proxy
  • 408 Limit czasu żądania
  • 409 Konflikt
  • 410 Przeminęło
  • 411 Wymagana długość
  • 412 Warunek wstępny nie powiódł się
  • 413 Ładowność zbyt duża
  • 414 URI Too Long
  • 415 Nieobsługiwany typ nośnika
  • 416 Zasięg niezadowalający
  • 417 Oczekiwanie nie powiodło się
  • 418 Jestem czajnikiem
  • 420 Błąd metody
  • 421 Błędnie skierowane żądanie
  • 422 Podmiot nieprzetworzony
  • 423 Zamknięty
  • 424 Nieudana zależność
  • 426 Wymagana aktualizacja
  • 428 Wymagany warunek wstępny
  • 429 Zbyt wiele wniosków
  • 431 Żądanie pól nagłówka jest zbyt duże
  • 451 Niedostępne z powodów prawnych

5XX Błędy serwera

  • 500 Błąd wewnętrzny serwera
  • 501 Nie zaimplementowano
  • 502 Zła brama
  • 503 Usługa niedostępna
  • Limit czasu bramy 504
  • 505 Wersja HTTP nie jest obsługiwana
  • 506 Varient Również negocjuj
  • 507 Niewystarczająca ilość miejsca
  • Wykryto pętlę 508
  • 510 Nie przedłużony
  • 511 Wymagane uwierzytelnienie sieciowe

3

W czerwcu 2014 r. RFC7231 przestarzałe RFC2616. Jeśli wykonujesz REST przez HTTP, to RFC7231 dokładnie opisuje, czego się oczekuje od GET, PUT, POST i DELETE


-1

Po zmodyfikowaniu zasobu kod odpowiedzi powinien wynosić 200 („OK”) . Jeśli stan zasobu zmienia się w sposób, który zmienia identyfikator URI na zasób (na przykład nazwa użytkownika zmienia nazwę), kod odpowiedzi to 301 („Przeniesiono na stałe”), a nagłówek lokalizacji powinien podać nowy identyfikator URI.

Po usunięciu obiektu kod odpowiedzi powinien wynosić 200 („OK”).

Kliknij poniższy link, aby uzyskać więcej informacji - kod stanu na odpoczynek

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.