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.
これがおそらくあなたの最善の策だと思います。