Uczę się ostatnio jQuery i nie przedłużając za bardzo, chciałbym zrealizować taką funkcjonalność:
Po stronie przeglądarki prosty przycisk wywołujący funkcję, która nawiązuje komunikację z użyciem AJAX do serwera, który ma kontroler RESTowy np. Po stronie serwera zdarzenie kliknięcia wspomnianego przycisku ma wywołać metodę. Metoda powiedzmy oczekuje jakiejś reakcji, np. niech by to było podanie z konsoli liczby 0-100. Dopóki się to nie stanie, chciałbym, aby po stronie klienta była informacja o oczekiwaniu (mogę sobie tu np. wrzucić obrazek GIF z ładowaniem do jakiegoś DIVa). Jeśli się to nie stanie w określonym czasie (jakiś timeout po stronie jQuery) znikała by informacja o oczekiwaniu i pojawiła by się informacja o błędzie. Jak dotąd "bawiłem się" prostą komunikacją z RESTem, pobierałem obiekty, prezentowałem je po stronie klienta, przesyłałem też proste stringi POSTem do serwisu RESTowego.
Jeśli chcesz żeby to serwer "oczekiwał na zmienną" to przez REST API raczej tego nie zrobisz, bo to co do zasady komunikacja bezstanowa - serwer zwraca Piotrkowi odpowiedź i zapomina, że gadał z Piotrkiem. Nie ma jak powiedzieć Piotrkowi, że czekał na niego całe 30s i nie dostał przycisku.
Podejrzewam, że prędzej udałoby Ci się to zrealizować z użyciem websockets niż kombinując by obejść ograniczenia REST API :)
Brak odpowiedzi ze strony serwera byłby obsłużony właśnie po stronie klienta, zdecydowanie.
Na takiej mniej więcej zasadzie:
$.ajax({
url: "jakis-url",
error: function(){
...
},
success: function(){
...
},
timeout: 3000
});
- Request POST, że ktoś wcisnął guzik, zwraca Ci jakiś identyfikator tej czynności. Zapisujesz gdzieś kiedy ktoś go wcisnął.
- Request POST z identyfikatorem z poprzedniego requesta i dodatkowo z tymi danymi, które ktoś wpisał. Zwraca 422, jeżeli od poprzedniego requesta minęło więcej niż 30 sek.
Resztę robisz po froncie, bo używając resta nie nawiążesz stałej komunikacji z serwerem. Tylko sockety. Można też całkowicie olać 1 call i po prostu ogarnąć wszystko po froncie. A jak masz już komplet danych zebrany to wtedy je wypchnąć do serwera, chyba że ważne jest, żeby ktoś podał te dane w tym oknie 30 sek, to musisz to walidować serwerowo, bo js można zhackować.
@tj4java wyżej napisałem, że w drugim callu request POST, ale to na dobrą sprawę zależy od twojego modelu. Jeżeli dane, które ktoś przesyła aktualizują encję, która została utworzona w pierwszym callu, to PUT albo PATCH.
tj4java napisał(a):
Brak odpowiedzi ze strony serwera byłby obsłużony właśnie po stronie klienta, zdecydowanie.
Na takiej mniej więcej zasadzie:$.ajax({ url: "jakis-url", error: function(){ ... }, success: function(){ ... }, timeout: 3000 });
No ok, ale serwer musi jeszcze wiedzieć że ma czekać na "coś jeszcze" i odpowiednio zareagować. Po pierwsze musi faktycznie oczekiwać na dalsze dane, po drugie musi być w stanie stwierdzić, że nie ma co dłużej czekać jeśli JS rzuci sobie błąd. Sam REST do tego nie służy, musisz być w stanie nawiązać dwukierunkową komunikację z serwerem, jeśli chcesz by serwer reagował w czasie i mógł zbierać dane w locie.
Ew. Możesz to olać, zrobić ten timeout w JS, ale żądanie wysłać dopiero, gdy użytkownik faktycznie poda liczbę - wtedy to będzie najzwyklejsze w świecie wywołanie API więc będzie ok, bo serwer przetworzy żądanie i zwróci odpowiedź.