Ajax calls from browser over Asynchronous Controller

Question

I am calling an external REST service (Vimeo REST API). The response of the service is JSON object. A single view in my application might end up making multiple calls to the service (for loading multiple videos).

I wanted to gauge the Pros and Cons of using the following architecture in this situation

1. using jquery ajax calls for loading individual videos (call made to the REST service from the browser as each video has its Id which is the only thing needed to get the details)
2. using ansynchronous controller action to make the REST call in the controller and then displaying the vedios

Note: I am using simple API services which do not require authentication.

Answer 1

AsyncController was not designed for the purpose of serving HTTP requests asynchronously, but for the purpose of executing long running server-side processes. Making a single request to REST service may or may not be a long running server-side process.

So, whether you decide to make the REST request server-side or directly from the client (browser), you do not necessarily need to use an AsyncController. A normal Controller might do the job.

How you should handle the video requests depends on how your business layer is structured. If there is knowledge of the Vimeo videos for processing in the business layer, then it is best practice to make your web-service calls service side. Otherwise, you have business logic on your client, which can make things difficult to maintain.

If on the other hand, your Vimeo videos are only part of a self-contained UI-widget, then it is safe to process the request completely on the client without incurring unexpected consequences.

I am assuming the web-service call to Vimeo receives a Flash file or something like it. It would require more bandwidth as well as cost more memory to make the Vimeo service calls from the server, because then the data has to go to your server.

If you do it server side, this happens:

 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

If you do it client side, this happens:

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

This makes it look like doing it all client-side is better. But then there is the whole business logic issue. This can be remedied by sending an ajax request to a synchronous controller action to do business logic processing, and having it return the URL of the call to the REST service to the browser. So:

 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.

I think this is probably your best bet.

Answer 2

You may have problems with the first method, because cross-domain ajax calls (the page opened is from yoursite.com domain, and you making a call to vimeo.com) are prohibited by the browsers.

In addition to the second method, you can use JSONP provided by Vimeo API: http://vimeo.com/api/docs/response-formats

Answer 3

If you are making multiple calls to Vimeo's REST service for a single action method, that would seem like a good candidate for using an asynchronous controller. This would have two benefits: it would allow you to execute multiple calls to Vimeo's service in parallel, and it would free up the thread that is handling the request and allow it to handle other requests while the server is waiting for a response from Vimeo.

I guess the trade-off here is adding complexity to your client code or to your controller code. Another benefit of making the requests on the server side (whether you do them asynchronously or not) is that you could potentially cache the data and minimize the number of expensive web service calls you have to make to handle requests in the future. That really depends on whether caching the data is a viable option in your situation.