Mam zbiór zasobów, których reprezentacje są leniwie tworzone. Obliczenia potrzebne do zbudowania tych reprezentacji mogą zająć od kilku milisekund do kilku godzin, w zależności od obciążenia serwera, określonego zasobu i fazy księżyca.
Pierwsze żądanie GET odebrane dla zasobu rozpoczyna obliczenia na serwerze. Jeśli obliczenia zakończy się w ciągu kilku sekund, zwracana jest obliczona reprezentacja. W przeciwnym razie zwracany jest kod stanu 202 „Zaakceptowano”, a klient musi odpytywać zasób, aż ostateczna reprezentacja będzie dostępna.
Przyczyna tego zachowania jest następująca: Jeśli wynik jest dostępny w ciągu kilku sekund, należy go pobrać tak szybko, jak to możliwe; w przeciwnym razie, kiedy stanie się dostępny, nie jest ważne.
Ze względu na ograniczoną pamięć i ogromną liczbę żądań, ani NIO, ani długie odpytywanie nie są opcją ( tj. Nie mogę utrzymać prawie wystarczającej liczby otwartych połączeń, ani nawet nie mogę nawet zmieścić wszystkich żądań w pamięci; raz „kilka sekund” minęły, podtrzymuję nadmiar żądań). Podobnie ograniczenia klienta są takie, że nie mogą zamiast tego obsługiwać wywołania zwrotnego zakończenia. Na koniec zwróć uwagę, że nie jestem zainteresowany tworzeniem zasobu „fabrycznego”, do którego się POST wysyła, ponieważ dodatkowe podróże w obie strony oznaczają, że zawodzimy odcinkowe ograniczenie czasu rzeczywistego bardziej niż jest to pożądane (ponadto jest to dodatkowa złożoność; ponadto jest to zasób, który korzyści z buforowania).
Wyobrażam sobie, że istnieją pewne kontrowersje dotyczące zwracania kodu stanu 202 „Zaakceptowano” w odpowiedzi na żądanie GET, ponieważ nigdy nie widziałem tego w praktyce, a jego najbardziej intuicyjne użycie jest odpowiedzią na niebezpieczne metody, ale nigdy nie znalazł coś szczególnie zniechęcającego. Co więcej, czy nie zachowuję jednocześnie bezpieczeństwa i idempotencji?
Więc co ludzie myślą o tym podejściu?
EDYCJA : Powinienem wspomnieć, że dotyczy to tak zwanego biznesowego internetowego interfejsu API - nie dla przeglądarek.
źródło
202. To, że jest rzadko używane w praktyce, jest bardziej IMHO, ponieważ niewielu programistów internetowych dba o prawidłowe kody statusu, ponieważ są bardziej przyzwyczajeni do interakcji przeglądarki / użytkownika-agenta, w którym to przypadku nie202daje im widocznej wskazówki (daj im200i są zadowoleni. ..).200.202jest tym, czym ma być, ale w praktyce ludzie się tego nie spodziewają202.Odpowiedzi:
Jeśli jest przeznaczony dla dobrze zdefiniowanego i udokumentowanego interfejsu API,
202brzmi dokładnie tak, jak to się dzieje.Jeśli chodzi o publiczny Internet, martwiłbym się zbytnio o zgodność klienta. Widziałem tak wiele
if (status == 200)zakodowanych na stałe ... W takim przypadku zwróciłbym plik200.Ponadto dokument RFC nie wskazuje, że użycie 202 dla żądania GET jest błędne, podczas gdy zawiera wyraźne rozróżnienia w innych opisach kodu (np. 200).
źródło
Zrobiliśmy to dla niedawnej aplikacji, klient (niestandardowa aplikacja, a nie przeglądarka) wysłał zapytanie POST i serwer zwrócił 202 z URI do wysyłanego "zadania" - klient użyłby tego URI do odpytania o wynik - wydaje się, że pasuje do tego, co zostało zrobione.
Najważniejsze jest tutaj udokumentowanie, jak działa twoja usługa / API i co oznacza odpowiedź 202.
źródło
Z tego co pamiętam - GET ma zwrócić zasób bez modyfikowania serwera. Może aktywność zostanie zarejestrowana lub co masz, ale żądanie powinno być ponownie uruchomione z tym samym wynikiem.
POST z drugiej strony to żądanie zmiany stanu czegoś na serwerze. Wstaw rekord, usuń rekord, uruchom zadanie, coś w tym rodzaju. 202 byłby odpowiedni dla POST, który zwrócił, ale nie został ukończony, ale tak naprawdę nie jest żądaniem GET.
To wszystko jest bardzo purytańskie i niezbyt dobrze praktykowane w naturze, więc prawdopodobnie jesteś bezpieczny, zwracając 202. GET powinien zwrócić 200. POST może zwrócić 200, jeśli zakończyło się, lub 202, jeśli nie zostało wykonane.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
źródło
W przypadku zasobu, który ma mieć reprezentację podmiotu, który jest wyraźnie określony identyfikatorem (w przeciwieństwie do zasobu „fabrycznego”, jak opisano w pytaniu), zalecam pozostanie przy metodzie GET i sytuacji, gdy jednostka / reprezentacja jest niedostępna z powodu leniwego tworzenia lub jakiejkolwiek innej tymczasowej sytuacji, użyj kodu odpowiedzi 503 Niedostępna usługa, który jest bardziej odpowiedni i został faktycznie zaprojektowany na potrzeby takich sytuacji.
Powód tego można znaleźć w dokumentach RFC dotyczących samego protokołu HTTP (proszę sprawdzić opis kodu odpowiedzi 503), a także w wielu innych zasobach.
Porównaj z kodem stanu HTTP dla tymczasowo niedostępnych stron . Chociaż to pytanie dotyczy innego przypadku użycia, w rzeczywistości dotyczy dokładnie tej samej funkcji protokołu HTTP.
źródło