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