Kod statusu HTTP do aktualizacji i usunięcia?

Jaki kod stanu powinienem ustawić dla UPDATE( PUT) i DELETE(np. Produkt pomyślnie zaktualizowany)?

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

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ć).

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

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.

RFC 2616 opisuje, których kodów stanu należy użyć .

I nie, nie zawsze jest to 200.

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.

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.

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

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

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