Как отмечает Брайан Агнью, 5 минут вполне поддаются управлению, если они несколько бесполезны, если можно контролировать настройки тайм-аута. В противном случае должно быть сделано по крайней мере два запроса: первый, чтобы запустить процесс создания результатов, а второй (и третий, четвертый, и т. Д. , если для компиляции результата требуется больше времени, чем ожидалось), опрос за результат.
Брайан Агнью и Даррел Миллер оба предлагают аналогичные подходы для двух (+) - пошагового подхода: POST-запрос к конечной точке фабрики, запуск задания на сервере и позднее ПОЛУЧЕНИЕ результата из возвращенной конечной точки результата.
Хотя вышеизложенное является очень распространенным решением и действительно соответствует букве ограничений REST, оно очень сильно пахнет RPC. То есть вместо того, чтобы сказать «предоставьте мне представление этого ресурса », в нем говорится «запустите это задание » (RPC), а затем «предоставьте мне представление ресурса, который является результатом выполнения задания "(REST). РЕДАКТИРОВАТЬ: Я говорю очень свободно здесь. Чтобы быть ясным, ничего из этого явно не противоречит ограничениям REST , но это очень похоже на одевание подхода без RESTful в одежде REST, теряя его преимущества ( например кеширование , идемпотентность) в процессе.
Таким образом, я бы предпочел, чтобы, когда клиент впервые попытался получить ресурс, сервер ответил 202 «Принят» (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3),, возможно, «повторить попытку через 5 минут» где-то в ответе). После этого клиент может опросить той же конечной точки , чтобы ПОЛУЧИТЬ результат, если он доступен (в противном случае вернуть еще 202 и повторить попытку позже).
Некоторые дополнительные преимущества этого подхода состоят в том, что одноразовые ресурсы (такие как задания) не создаются излишне, две отдельные конечные точки не должны запрашиваться (фабрика и результат), и аналогично вторая конечная точка не должна быть определена из анализа Ответ от первого, таким образом, проще. Кроме того, результаты могут быть кэшированы «бесплатно» (по кодам). Установите время истечения срока действия кэша в заголовке результата в соответствии с тем, как долго результаты являются «действительными», в некотором смысле, для вашей проблемной области.
Хотелось бы, чтобы я назвал это учебным примером "ресурсно-ориентированного" подхода, но, возможно, по иронии судьбы, в главе 8 "RESTful Web Services" предлагается фабричный подход с двумя конечными точками. Пойди разберись.