Ajax-вызовы из браузера через асинхронный контроллер

AsyncController был разработан не для асинхронного обслуживания HTTP-запросов, а для выполнения длительных процессов на стороне сервера. Выполнение одного запроса к службе REST может быть или не быть длительным процессом на стороне сервера.

Таким образом, независимо от того, решите ли вы сделать запрос REST на стороне сервера или напрямую от клиента (браузера), вам не обязательно использовать файл AsyncController. Обычный Controller может справиться с этой задачей.

То, как вы должны обрабатывать видеозапросы, зависит от того, как структурирован ваш бизнес-уровень. Если есть знания о видео Vimeo для обработки на бизнес-уровне, то лучше всего сделать так, чтобы ваш веб-сервис вызывал сервисную сторону. В противном случае у вас есть бизнес-логика на вашем клиенте, что может затруднить обслуживание.

Если, с другой стороны, ваши видео Vimeo являются лишь частью автономного UI-виджета, то можно безопасно обрабатывать запрос полностью на клиенте без непредвиденных последствий.

Я предполагаю, что вызов веб-службы Vimeo получает файл 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 в действие синхронного контроллера для выполнения обработки бизнес-логики и вернув браузеру URL-адрес вызова службы REST. Так:

 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.

Я предполагаю, что компромисс здесь заключается в усложнении кода вашего клиента или кода вашего контроллера. Еще одно преимущество выполнения запросов на стороне сервера (независимо от того, делаете ли вы их асинхронно или нет) заключается в том, что вы потенциально можете кэшировать данные и свести к минимуму количество дорогостоящих вызовов веб-службы, которые вам придется делать для обработки запросов в будущем. Это действительно зависит от того, является ли кэширование данных жизнеспособным вариантом в вашей ситуации.