我正在调用外部REST服务（Vimeo REST API）。服务的响应是JSON对象。我的应用程序中的单个视图最终可能会多次调用该服务（用于加载多个视频）。
我想衡量在这种情况下使用以下架构的优点和缺点
注意：我使用的是不需要身份验证的简单API服务。
答案 0 :(得分：3)
AsyncController不是为了异步提供HTTP请求而设计的，而是为了执行长时间运行的服务器端进程。对REST服务发出单个请求可能是也可能不是长时间运行的服务器端进程。
因此，无论您是决定在服务器端进行REST请求还是直接从客户端（浏览器）进行REST请求，您都不一定需要使用AsyncController。正常Controller可能会完成这项工作。
您应如何处理视频请求取决于您的业务层的结构。如果知道要在业务层中处理的Vimeo视频，那么最佳做法是将您的Web服务调用服务端。否则，您的客户端就有业务逻辑，这可能会使维护变得困难。
另一方面，如果您的Vimeo视频只是自包含UI小部件的一部分，那么在客户端上完全处理请求是安全的，而不会产生意外后果。
我假设对Vimeo的Web服务调用收到Flash文件或类似的东西。它需要更多的带宽以及更多的内存来从服务器进行Vimeo服务调用，因为这样数据就必须送到你的服务器。
如果你在服务器方面这样做，就会发生这种情况：
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
如果你在客户端这样做，就会发生这种情况：
1 - Browser sends HTTP-Request to Vimeo's WebService
2 - Vimeo's WebService sends big HTTP Response with the Video data to the Browser
这使得它看起来像做所有客户端更好。但那时存在整个业务逻辑问题。这可以通过向同步控制器动作发送ajax请求来执行业务逻辑处理，并让它将对REST服务的调用URL返回给浏览器来解决。所以：
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.
我认为这可能是你最好的选择。
答案 1 :(得分：0)
第一种方法可能有问题，因为浏览器禁止跨域ajax调用（打开的页面来自yoursite.com域，并且您调用vimeo.com）。
除了第二种方法，您还可以使用Vimeo API提供的JSONP：http://vimeo.com/api/docs/response-formats
答案 2 :(得分：0)
如果您为单个操作方法多次调用Vimeo的REST服务，那么这似乎是使用异步控制器的一个很好的选择。这有两个好处：它允许您并行执行对Vimeo服务的多个调用，并且它将释放处理请求的线程，并允许它在服务器等待Vimeo的响应时处理其他请求。
我想这里的权衡是增加客户端代码或控制器代码的复杂性。在服务器端发出请求（无论是否异步执行）的另一个好处是，您可以缓存数据并最大限度地减少将来处理请求时必须进行的昂贵Web服务调用的次数。这实际上取决于在您的情况下缓存数据是否可行。