Zastanawiałem się, jakie są opinie ludzi na temat PUToperacji RESTful , która nie zwraca nic (zero) w treści odpowiedzi.
Zastanawiałem się, jakie są opinie ludzi na temat PUToperacji RESTful , która nie zwraca nic (zero) w treści odpowiedzi.
Odpowiedzi:
Specyfikacja HTTP ( RFC 2616 ) zawiera szereg odpowiednich zaleceń. Oto moja interpretacja:
200 OKdla udanego PUT aktualizacji istniejącego zasobu. Nie wymaga odpowiedzi. (Per sekcji 9.6 , 204 No Contentjest nawet bardziej odpowiednie).201 Createdudanego PUT nowego zasobu, z najbardziej szczegółowym identyfikatorem URI dla nowego zasobu zwróconym w polu nagłówka Lokalizacja oraz wszelkimi innymi istotnymi identyfikatorami URI i metadanymi zasobu, które są powtarzane w treści odpowiedzi. ( RFC 2616 sekcja 10.2.2 )409 Conflictdla PUT, że nie powiedzie się ze względu na 3 -cim modyfikacji -party, z listą różnic między próbą aktualizacji i aktualnego zasobu w organizmie reakcji. ( RFC 2616 sekcja 10.4.10 )400 Bad Requestdla nieudanego testu PUT z tekstem w języku naturalnym (takim jak angielski) w treści odpowiedzi, który wyjaśnia, dlaczego test PUT nie powiódł się. ( RFC 2616 sekcja 10.4 )No response body neededw odniesieniu do 200. W rzeczywistości ciało odpowiedzi w ogóle nie jest wymienione w odniesieniu do PUT. To tylko stwierdzaIf an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.
W przeciwieństwie do większości odpowiedzi tutaj, myślę, że PUT powinien zwrócić zaktualizowany zasób (oprócz kodu HTTP oczywiście).
Powodem, dla którego chcesz zwrócić zasób jako odpowiedź na operację PUT, jest to, że gdy wysyłasz reprezentację zasobu do serwera, serwer może również zastosować pewne przetwarzanie do tego zasobu, więc klient chciałby wiedzieć, w jaki sposób ten zasób wyglądają jak po pomyślnym zakończeniu żądania. (w przeciwnym razie będzie musiał wydać kolejne żądanie GET).
Myślę, że serwer może zwrócić treść w odpowiedzi na PUT. Jeśli używasz formatu obwiedni odpowiedzi, który pozwala na ładowanie danych z boku (na przykład format zużywany przez ember-data), możesz również uwzględnić inne obiekty, które mogły zostać zmodyfikowane za pomocą wyzwalaczy bazy danych itp. (Dane z ładowaniem bocznym mają wyraźnie na celu zmniejszenie Liczba żądań, a to wydaje się być dobrym miejscem do optymalizacji).
Jeśli akceptuję PUT i nie mam nic do zgłoszenia, używam kodu statusu 204 bez treści. Jeśli mam coś do zgłoszenia, używam kodu stanu 200 i dołączam ciało.
Specyfikacja HTTP / 1.1 (sekcja 9.6) omawia odpowiednie kody odpowiedzi / błędów. Nie dotyczy to jednak treści odpowiedzi.
Czego byś oczekiwał Prosty kod odpowiedzi HTTP (200 itd.) Wydaje mi się prosty i jednoznaczny.
Jeśli zapleczem interfejsu API REST jest relacyjna baza danych SQL, to
Jeśli nie przejmujesz się utraconymi aktualizacjami lub jeśli chcesz zmusić swoich klientów do wykonania GET natychmiast po PUT, nie zwracaj niczego z PUT.
Kod odpowiedzi 201 dla „Utworzono” wraz z nagłówkiem „Lokalizacja”, aby wskazać, gdzie klient może znaleźć nowo utworzony zasób.
Użyłem RESTful API w moich usługach i oto moja opinia: Najpierw musimy przejść do wspólnego widoku ：PUTsłuży do aktualizacji zasobu, którego nie można utworzyć ani uzyskać.
Zdefiniowałem zasoby za pomocą: Stateless resourcei Stateful resource:
Zasoby bezstanowe W przypadku tych zasobów wystarczy zwrócić kod HttpCode z pustym ciałem, wystarczy.
Zasoby stanowe Na przykład: wersja zasobu. W przypadku tego rodzaju zasobów musisz podać wersję, gdy chcesz ją zmienić, więc zwróć pełny zasób lub zwróć wersję klientowi, aby klient nie musiał wysyłać żądania get po aktualizacji.
Ale , na usługi lub systemu, zachować to simple, clearly, easy to use and maintainjest najważniejszą rzeczą.
Podobnie jak pusta treść żądania jest zgodna z pierwotnym celem żądania GET, a pusta treść odpowiedzi jest zgodna z pierwotnym celem żądania PUT.
wydaje się ok ... choć sądzę, że szczątkowy wskaźnik sukcesu / niepowodzenia / opublikowanego czasu / odebranych bajtów / etc. byłoby lepiej.
edycja: Myślałem zgodnie z zasadą integralności danych i / lub prowadzenia dokumentacji; metadane, takie jak skrót MD5 lub znacznik czasu dla odebranego czasu, mogą być pomocne w przypadku dużych plików danych.
Idealnie byłoby zwrócić odpowiedź sukces / porażka.
Istnieje różnica między nagłówkiem a treścią odpowiedzi HTTP. PUT nigdy nie powinien zwracać treści, ale musi zwracać kod odpowiedzi w nagłówku. Wybierz 200, jeśli się powiedzie, i 4xx, jeśli nie. Nie ma czegoś takiego jak zerowy kod powrotu. Dlaczego chcesz to zrobić?
200PUT, DELETE lub jakiejkolwiek innej metody. Przegapiłem coś? Takich jak Mozilla zostaje szefem W3 i IETF? ;) A może po prostu nigdy nie słyszeli o zasadzie solidności Postela.