Jakie wywołania REST PUT / POST / DELETE powinny być zwracane przez konwencję?

153

  1. Co zgodnie z ideologią „REST” powinno znajdować się w treści odpowiedzi na żądania PUT / POST / DELETE?

  2. A co z kodami zwrotnymi? Czy HTTP_OKwystarczy?

  3. Jaki jest powód takich konwencji, jeśli w ogóle?

Znalazłem dobry post opisujący różnice POST / PUT: POST vs PUT Ale nadal nie odpowiada na moje pytanie.

rest http post http-delete tuxSlayer
źródło

Odpowiedzi:

130

Wybacz sobie nonszalancję, ale jeśli robisz REST przez HTTP, to RFC7231 opisuje dokładnie, jakiego zachowania oczekuje się od GET, PUT, POST i DELETE.

Aktualizacja (lipiec 3 2014):
specyfikacja HTTP celowo nie definiuje, co jest zwracane z POST lub DELETE. Specyfikacja określa tylko to, co należy zdefiniować. Reszta pozostaje do wyboru wdrażającego.

Darrel Miller
źródło
9
@tuxslayer Cieszę się, że nie pomyślałeś, że po prostu próbowałem być wredny. Wiele osób uważa, że ​​REST dodaje dodatkowe wymagania do metod HTTP. Jednak tak nie jest. Istnieją dodatkowe ograniczenia, ale tak naprawdę nie wpływają one na zachowanie metod HTTP. RFC2616 jest zdecydowanie przewodnikiem do naśladowania.
Darrel Miller,
4
Doceniam link. :) To sprawiło, że zatrzymałem się i pomyślałem o narzędziu, którego używam. Po przeczytaniu twojego postu i RFC, odnalazłem się na RFC przez resztę nocy. Pomogło mi to najpierw myśleć o procesie jako o procesie HTTP, a potem o procesie odpoczynku. Bardzo cenione.
Perry Tew,
4
@PerryTew Teraz możesz przejść tutaj tools.ietf.org/wg/httpbis i zobaczyć aktualnie aktualizowaną wersję specyfikacji HTTP. Cieszyć się!
Darrel Miller,
12
Może po prostu potrzebuję więcej snu, ale nie mogę znaleźć dokładnych informacji, o które prosił OP w RFC. Jaka powinna być treść odpowiedzi POST lub DELETE?
Cam Jackson,
9
Cóż, to jest tak jasne jak błoto. Może trochę więcej informacji w odpowiedzi byłoby pomocne. Zwłaszcza, gdy ten link jest martwy.
Doug Molineux
25

Ogólnie rzecz biorąc, konwencje to „myśl, jakbyś tylko dostarczał strony internetowe”.

W przypadku PUT zwróciłbym ten sam widok, który uzyskasz, gdybyś zrobił GET natychmiast po; dałoby to 200 (cóż, zakładając oczywiście, że renderowanie się powiedzie). W przypadku POST wykonałbym przekierowanie do utworzonego zasobu (zakładając, że wykonujesz operację tworzenia; jeśli nie, po prostu zwróć wyniki); kod do pomyślnego utworzenia to 201, który jest tak naprawdę jedynym kodem HTTP przekierowania spoza zakresu 300.

Nigdy nie byłem zadowolony z tego, co powinno zwrócić DELETE (mój kod obecnie tworzy HTTP 204 i pustą treść w tym przypadku).

Donal Fellows
źródło
1
Zwrócenie PUTżądania na następną stronę wydaje się złą praktyką, ponieważ odświeżenie strony wynikowej spowoduje ponowne wykonanie żądania. Zamiast tego dla mnie sensowne jest wykonanie przekierowania, zakładając, że masz do czynienia z żądaniami synchronicznymi.
lobati
1
@lobati Myślę, że ważne jest, aby pamiętać, że wysłanie wielu identycznych żądań PUT powinno mieć dokładnie taki sam wynik, jak wysłanie tylko jednego z tych samych żądań PUT. Być może poruszona przez Ciebie kwestia jest teraz mniej ważna, biorąc pod uwagę powyższe?
Iain
3
@ Naprawdę nie. Problem polega na tym, że jeśli coś innego zaktualizuje rekord później, nie chcesz, aby wysyłało kolejne PUTżądanie powodujące przywrócenie danych. Na przykład, jeśli dwie osoby odwołują się do tej samej strony, jedna dokonuje aktualizacji, a następnie druga dokonuje aktualizacji, jeśli pierwsza osoba odświeży się, aby zobaczyć wynik, w rzeczywistości spowoduje to, że rzeczy zostaną przywrócone, zanim zrobi to druga osoba ich zmiany.
lobati
„Pomyśl jak witryna” jest doskonałe, dlatego usunięcie może odpowiadać niektórymi prawdopodobnymi kolejnymi działaniami, które zależą od „historii” dotyczącej przyczyny usunięcia zasobu. Może to być przynajmniej łącze, które przeniesie agenta z powrotem do jakiegoś logicznego miejsca rozpoczęcia działań, a nawet przekierowanie do zasobu statusu, który pokazuje wpływ usunięcia (suma zamówienia) i zawiera dalsze linki.
Luke Puplett
3

Tworzenie zasobu jest zazwyczaj mapowane do POST, co powinno zwrócić lokalizację nowego zasobu; na przykład w rusztowaniu Railsowym CREATE przekieruje do POKAŻ dla nowo utworzonego zasobu. To samo podejście może mieć sens w przypadku aktualizacji (PUT), ale to mniej konwencji; aktualizacja musi tylko wskazywać na sukces. Usunięcie prawdopodobnie musi tylko oznaczać sukces; jeśli chcesz przekierować, zwrócenie LISTY zasobów prawdopodobnie ma największy sens.

Sukces może być wskazany przez HTTP_OK, tak.

Jedyną twardą i szybką regułą w tym, co powiedziałem powyżej, jest to, że CREATE powinno zwrócić lokalizację nowego zasobu. Wydaje mi się to oczywiste; ma sens, że klient będzie musiał mieć dostęp do nowej pozycji.

Jacob Mattison
źródło
2
Właściwie pomieszałeś PUT i POST. POST służy do tworzenia, PUT służy do aktualizacji (i tworzenia). Warto również zauważyć, że PUT powinien być idempotentny, podczas gdy POST nie.
Stevie
Idempotentne polecenie powinno działać poprawnie, niezależnie od tego, ile razy je uruchomisz. Dlatego powinieneś być w stanie wykonać to samo PUT wiele razy, aby zastosować tę samą „aktualizację” bez żadnych negatywnych skutków ubocznych.
Jacob Mattison
1

Według RFC7231 nie ma to znaczenia i może być puste

Jak wdrażamy w projekcie rozwiązanie oparte na standardzie JSON API:

post / put: wyprowadza atrybuty obiektu jak w get (filtr pól / relacje działają tak samo)

usuń: dane zawierają tylko wartość null (jako reprezentacja brakującego obiektu)

status usuwania standardowego: 200

Marius Gri
źródło
0

Podoba mi się odpowiedź Alfonso Tienda z kodu statusu HTTP do aktualizacji i usunięcia?

Oto kilka porad:

USUNĄĆ

  • 200 (jeśli chcesz przesł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, operacja usunięcia już usuniętego elementu zakończyła się pomyślnie , więc możesz zwrócić 204 , ale prawdą jest, że idempotent niekoniecznie oznacza tę samą odpowiedź)

Inne błędy:

  • 400 Złe żądanie (zniekształcona składnia lub nieprawidłowe 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 wykonana.

Element, którego dotyczy odwołanie, nie istnieje:

  • PUT może wynosić 201 (jeśli utworzyłeś element, ponieważ takie jest twoje zachowanie)

  • 404 Jeśli nie chcesz tworzyć elementów za pomocą PUT.

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

  • 401 Unauthorized

  • 403 Zabronione : błąd uwierzytelniania 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 przypadku DELETE.

  • 422 Jednostka, której nie można przetwarzać Pomaga odróżnić „Złe żądanie” (np. Źle sformułowany XML / JSON) od nieprawidłowych wartości pól

  • I 501 , 502 w przypadku błędów.

Ryabchenko Alexander
źródło