我正在調用外部REST服務（Vimeo REST API）。服務的響應是JSON對象。我的應用程序中的單個視圖最終可能會多次調用該服務（用於加載多個視頻）。瀏覽器通過異步控制器進行的Ajax調用
我想衡量利弊使用jquery Ajax調用加載單個視頻（調用從瀏覽器到REST服務進行的每部影片都有它的標識使用以下架構在這種情況下
注意瞭解詳細內容）
AsyncController不是爲了異步服務HTTP請求而設計的，而是爲了執行長時間運行的服務器端進程。向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.
我認爲這可能是你最好的選擇。
您可能會遇到第一種方法的問題，因爲跨域ajax調用（打開的頁面來自yoursite.com域，並且您打電話給vimeo.com）被瀏覽器禁止。
除了第二種方法，可以使用JSONP通過Vimeo的API提供：http://vimeo.com/api/docs/response-formats
如果您對單一的操作方法的Vimeo的REST服務進行多次調用，這似乎是一個很好的候選人使用一個異步控制器。這有兩個好處：它允許您並行執行對Vimeo服務的多個調用，並且它將釋放正在處理請求的線程，並允許它在服務器等待Vimeo的響應時處理其他請求。
我想這裏的權衡會增加客戶端代碼或控制器代碼的複雜性。在服務器端發出請求的另一個好處（無論是否異步執行）是，您可以緩存數據，並儘量減少將來處理請求所需的昂貴Web服務調用數量。這真的取決於緩存數據是否是一種可行的選擇。