Ajax chiamate dal browser nel corso asincrono controller

Question

che io chiamo un servizio REST esterna (Vimeo API REST). La risposta del servizio è oggetto JSON. Una visione unica nella mia applicazione potrebbe finire per fare più chiamate al servizio (per il caricamento di più video).

Ho voluto valutare i pro ei contro di utilizzare la seguente architettura in questa situazione

1. utilizzando chiamate jQuery Ajax per il caricamento di singoli video (chiamata fatta al servizio REST dal browser come ogni video ha il suo ID che è l'unica cosa necessaria per ottenere i dettagli)
2. con azione di controllo ansynchronous per effettuare la chiamata REST nel controller e quindi la visualizzazione dei vedios

Nota:. Sto usando servizi API semplici che non richiedono l'autenticazione

Answer 1

AsyncController non è stato progettato con lo scopo di servire richieste HTTP in modo asincrono, ma per lo scopo di eseguire lunghi processi in esecuzione sul lato server. Esecuzione di una sola richiesta al servizio REST può o non può essere un processo lungo sul lato server in esecuzione.

Quindi, se si decide di fare il lato server richiesta REST o direttamente dal client (browser), non si deve necessariamente utilizzare un AsyncController. Un Controller normale potrebbe fare il lavoro.

Come si deve gestire le richieste di video dipende da come il vostro livello di business è strutturato. Se v'è la conoscenza dei video Vimeo per l'elaborazione nel livello di business, allora è delle migliori pratiche per rendere il vostro web-service lato servizio chiamate. In caso contrario, si ha la logica di business sul client, che può rendere le cose difficili da mantenere.

Se d'altra parte, i tuoi video Vimeo sono solo una parte di una UI-widget di self-contained, allora è sicuro per elaborare la richiesta completamente sul client senza incorrere in conseguenze inaspettate.

Io parto dal presupposto della chiamata web-service a Vimeo riceve un file Flash o qualcosa di simile. Si richiederebbe più larghezza di banda così come costo più memoria per effettuare le chiamate di servizio Vimeo dal server, perché poi i dati deve andare al server.

Se lo fate lato server, questo accade:

 1 - Browser sends HTTP-Request to YourApplication
 2 - YourApplication sends HTTP-Request to Vimeo's WebService
 3 - Vimeo's WebService sends big HTTP Response with the Video data to YourApplication
 4 - YourApplication sends big HTTP Response with the Video data to Browser

 * If you choose to do it this way, this might be the point at which it makes sense to use an AsyncController

Se lo fate lato client, questo accade:

 1 - Browser sends HTTP-Request to Vimeo's WebService
 2 - Vimeo's WebService sends big HTTP Response with the Video data to the Browser

Questo lo rende simile a fare tutto sul lato client è meglio. Ma poi c'è tutta la questione logica di business. Questo può essere risolto con l'invio di una richiesta Ajax per un'azione di controllo sincrono a fare l'elaborazione logica di business, e averlo restituire l'URL della chiamata al servizio REST al browser. Quindi:

 1 - Browser sends AJAX request to YourApplication
 2 - YourApplication handles business logic and sends the URL of the REST request to Browser
 3 - Browser sends AJAX request to Vimeo's WebService
 4 - Vimeo's WebService sends big HTTP response with the video data to the browser.

Credo che questa è probabilmente la soluzione migliore.

Answer 2

Si possono avere problemi con il primo metodo, in quanto le chiamate cross-domain Ajax (la pagina aperta è da yoursite.com dominio, e si effettua una chiamata a vimeo.com) sono vietate dai browser.

Oltre al secondo metodo, è possibile utilizzare JSONP fornita da Vimeo API: http: // vimeo.com/api/docs/response-formats

Answer 3

Se si stanno facendo più chiamate al servizio REST di Vimeo per un singolo metodo di azione, che potrebbe sembrare un buon candidato per l'utilizzo di un controller asincrono. Ciò avrebbe due vantaggi: permetterebbe di eseguire più chiamate al servizio di Vimeo in parallelo, e sarebbe liberare il filo che sta gestendo la richiesta e permettono di gestire altre richieste mentre il server è in attesa di una risposta da Vimeo.

Credo che il trade-off qui è l'aggiunta di complessità al codice cliente o al codice del controller. Un altro vantaggio di fare le richieste sul lato server (se fare loro in modo asincrono o no) è che si potrebbe potenzialmente memorizzare nella cache i dati e ridurre al minimo il numero di servizio web costoso chiamate si deve fare per gestire le richieste in futuro. Questo in realtà dipende se la cache dei dati è una valida opzione nella vostra situazione.