Budujemy usługę REST, która zajmie około 5 minut. Będzie on wywoływany tylko kilka razy dziennie przez wewnętrzną aplikację. Czy wystąpił problem z żądaniem REST (np. HTTP), który trwa 5 minut?Podejście do żądania REST o długim czasie realizacji?
Czy musimy martwić się przekroczeniem limitów czasu? Czy powinniśmy uruchamiać żądanie w osobnym wątku na serwerze i przeprowadzić ankietę dla klienta?
Zakładając, że możesz skonfigurować limity czasu HTTP przy użyciu dowolnie wybranego schematu, możesz poprosić przez GET i zawiesić go na 5 minut.
Jednak może być bardziej elastyczne inicjowanie wykonania przez POST, otrzymanie paragonu (numer/id dowolne), a następnie wykonanie GET z wykorzystaniem tego 5 minut później (i może ponowić próbę, ponieważ procedura nie będzie za każdym razem dokładnie 5 minut). Jeśli żądanie jest nadal w toku, zwróć odpowiedni kod błędu HTTP (prawdopodobnie 404, ale co zwrócisz za GET z nieistniejącym paragonem?) Lub zwróć wyniki, jeśli są dostępne.
Jeśli kontrolujesz oba końce , możesz robić, co chcesz. Na przykład. przeglądarki zwykle uruchamiają żądania HTTP z nagłówkami "close close", więc masz mniej opcji ;-)
Pamiętaj, że jeśli masz trochę NAT/Firewalle pomiędzy, możesz mieć kilka połączeń drop, jeśli są nieaktywne przez jakiś czas.
Czy mogę zasugerować zarejestrowanie procedury "oddzwonienia"? Klient wysyła żądanie z "punktem końcowym oddzwonienia" do serwera, otrzymuje "bilet". Po zakończeniu działania serwera "oddzwoni" do klienta ... lub klient może sprawdzić status żądania za pomocą identyfikatora biletu.
To jest jedno podejście.
Utwórz nowy wniosek o przeprowadzenie ProcessXYZ
POST /ProcessXYZRequests
201-Created
Location: /ProcessXYZRequest/987
Jeśli chcesz zobaczyć aktualny status wniosku:
GET /ProcessXYZRequest/987
<ProcessXYZRequest Id="987">
<Status>In progress</Status>
<Cancel method="DELETE" href="/ProcessXYZRequest/987"/>
</ProcessXYZRequest>
gdy wniosek jest gotowy by zobaczyć coś
GET /ProcessXYZRequest/987
<ProcessXYZRequest>
<Status>Completed</Status>
<Results href="/ProcessXYZRequest/Results"/>
</ProcessXYZRequest>
Korzystając z tego podejścia, można łatwo wyobrazić sobie następujące żądania ould dać
GET /ProcessXYZRequests/Pending
GET /ProcessXYZRequests/Completed
GET /ProcessXYZRequests/Failed
GET /ProcessXYZRequests/Today
Jak Brian Agnew zaznacza, 5 minut jest całkowicie do opanowania, jeśli nieco marnotrawienia zasobów, jeśli można kontrolować ustawienia limitu czasu. W przeciwnym razie muszą zostać wykonane co najmniej dwie prośby: pierwsza, aby uzyskać wynik procesu produkcyjnego toczenia, a druga (i trzecia, czwarta, itd., jeśli wynik trwa dłużej niż oczekiwano, aby skompilować), aby odpytać za wynik .
Brian Agnew i Darrel Miller zarówno sugerują podobne podejścia dla dwóch (+) - kroków podejścia: POST żądanie do fabrycznego punktu końcowego, rozpoczęcie pracy na serwerze, a później GET wynik z zwróconego wyniku końcowego.
Chociaż powyższe jest bardzo powszechnym rozwiązaniem i rzeczywiście przestrzega litery ograniczeń REST, to bardzo pachnie RPC.To znaczy, zamiast mówić: "przedstaw mi reprezentację tego zasobu", mówi "uruchom tę zlecenie" (RPC), a następnie "dostarcz mi reprezentację zasobu, który jest wynikiem wykonywania pracy" (ODPOCZYNEK). EDYCJA: Mówię tu bardzo luźno. Aby być jasnym, żadne z nich wyraźnie nie sprzeciwia się restrykcjom REST, ale bardzo przypomina to przygotowanie niezobowiązującego podejścia w odzieży REST, tracąc na tym korzyści (, np. buforowanie, idempotencja) w procesie.
Jako takie, wolałbym zasugerować, że gdy klient po raz pierwszy próbuje pobrać zasobu, serwer powinien odpowiedzieć 202 "Zaakceptowany" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3), być może z "spróbuj ponownie w 5 minut" gdzieś w jednostce odpowiedzi. Następnie klient może sondować ten sam punkt końcowy,, aby uzyskać wynik, jeśli jest dostępny (w przeciwnym razie zwrócić inny 202 i spróbować ponownie później).
Niektóre dodatkowe korzyści wynikające z tego podejścia są takie, że zasoby jednorazowego użytku (takie jak zadania) nie są niepotrzebnie tworzone, dwa oddzielne punkty końcowe nie muszą być sprawdzane (fabryka i wynik), podobnie drugi punkt końcowy nie musi być określany na podstawie analizy składniowej odpowiedź od pierwszej, tym samym prostsza. Co więcej, wyniki mogą być buforowane, "za darmo" (w sensie kodowym). Ustaw czas wygaśnięcia pamięci podręcznej w nagłówku wyników zgodnie z tym, jak długo wyniki są "prawidłowe", w pewnym sensie dla domeny problemów.
Chciałbym móc nazwać to podręcznikowym przykładem "zorientowanego na zasoby" podejścia, ale, być może, ironicznie, rozdział 8 "RESTful Web Services" sugeruje podejście oparte na dwóch punktach końcowych. Domyśl.
Czy to nie jest stanowe (na serwerze) i nie jest stanowe zachowanie przeciwko ideałom REST? –
@Merlyn Morgan-Graham: to nie jest stanowość, która jest "przeciw ideałom REST", to jest ukryty stan. Ponieważ stan jest dostępny jako zasób pod danym adresem URL, jest to w porządku. –