Долгоживущие RESTful-взаимодействия

Я бы реализовал это следующим образом:

1) клиент запрашивает метаданные
2) сервер возвращает либо фактические данные (если они уже доступны), либо маркер NotReady
3) клиент спрашивает сервер, когда данные будут доступны (этот шаг можно объединить с предыдущим)
4 ) сервер возвращает временной интервал (могут быть некоторые эвристики для общего количества выполняемых заданий и т. д.)
5) клиент ждет указанный период времени и переходит к шагу 1

Таким образом, вы можете предоставлять данные клиентам как можно быстрее. Вы можете формировать нагрузку на сервер, настраивая интервал задержки, возвращаемый на шаге 4)

предоставление канала Atom для каждого ресурса, чтобы клиент подписывался на события обновления, а не просто ПОЛУЧАЛ ресурс (кажется слишком сложным и, возможно, ресурсоемким, если есть много активных документов)

Рассматривали ли вы SUP?

Если возможен опрос, зачем заморачиваться с фидом? Почему бы клиентам просто не опросить сам ресурс?

Не могли бы вы сократить количество ненужных опросов, включив расчетное время завершения анализа?

Используйте HTTP 202 Accepted.

Кроме того, ознакомьтесь с веб-сервисами RESTful — здесь я узнал о вышеизложенном. .

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

Действительно ли GET, который со временем возвращает разные результаты, означает, что он не является идемпотентным? В спецификации указано:

Методы также могут иметь свойство «идемпотентности» в том смысле, что (помимо ошибок или проблем с истечением срока действия) побочные эффекты N> 0 идентичных запросов такие же, как и для одного запроса.

То есть несколько вызовов GET могут возвращать разные результаты, если сами вызовы не имеют побочных эффектов.

В этом случае, возможно, ваш метод REST может использовать условный механизм GET и кэширования, чтобы указать, когда это будет сделано:

• While the analysis is in progress, a GET {docURI}/metadata response could have:
  • an Expires header set to a few seconds in the future.
  • нет заголовка ETag.
• Once the analysis is done, responses for that resource have:
  • no Expires header.
  • ETag. Последующие запросы с ETag должны возвращать 304 Not Modified.

NB вы можете рассмотреть другие заголовки ответа, связанные с кэшированием, а не только Expires.

Это «ощущается» как дизайн RESTful — вы можете представить, что веб-браузер делает правильные вещи, выполняя последовательные запросы к этому ресурсу.

«Просто иметь GET, возвращающий все, что доступно в то время», имеет массу смысла. За исключением того, что когда они проводят опрос, вы не хотите продолжать возвращать то, что они уже знают. Ответы становятся длиннее с каждым опросом.

Вам нужно, чтобы они предоставили вам свое «то, что я видел до сих пор» в запросе GET. Это дает вам идемпотентность. Если они просят чанк 1, они всегда получают один и тот же ответ. Как только они увидят кусок 1, они могут попросить кусок 2.

Ответ не становится больше. Становится доступно больше частей. GET "на уровне коллекции" предоставляет размер ответа. У вас есть GET на уровне детализации для каждой доступной части.

По сути, это алгоритм, аналогичный подтверждению TCP/IP. Когда они принимают кусок, вы отправляете следующий кусок. Если есть следующий кусок, в противном случае вы отправляете 200-ничего нового в отчете.

«Проблема, связанная с тем, что клиент знает, когда мы, наконец, закончим», не имеет значения. Они не могут знать, и вы не можете предсказать, сколько времени это займет.

Вы не хотите, чтобы они занимались «занятым ожиданием» — опросом, чтобы узнать, закончили ли вы еще — это довольно большая нагрузка на ваш сервер. Если они нетерпеливы. Вы можете ограничить их запросы. Вы можете отправить им «проверить через x секунд», где x будет постепенно увеличиваться.

Вы даже можете использовать алгоритм планировщика в стиле Unix, где их счет снижается, когда они опрашивают, и повышается, если они не опрашивают в течение X секунд.

Альтернативой является своего рода очередь, в которой вы отправляете им результаты. Для этого они должны предоставить URI, который вы можете отправить, чтобы сообщить им, что вы закончили.

Или они используют Atom для облегченной архитектуры опроса. Хотя Atom кажется сложным — и он по-прежнему включает в себя опрос — вы предоставляете минимальный ответ Atom («еще не изменен»), пока не закончите, когда вы предоставляете («новые результаты»), чтобы они могли выполнить настоящую работу. тяжелый вес. Это для «все или ничего», а не для описанной выше техники инкрементного ответа.

Вы также можете думать о GET «уровня коллекции» как о своем статусе Atom в процессе в целом.

Одним из альтернативных решений, которое может подойти или не подойти в вашем случае, является добавление новой конечной точки под названием «AnnotationRequests». Отправьте документ (или ссылку на него) в конечную точку AnnotationRequests, и он должен вернуть местоположение (например, http://example.org/AnnotationRequest/2042), что позволит вашему клиенту опрашивать статус процесса. По завершении процесса представление AnnotationRequest может содержать ссылку на готовый документ.

Одним приятным побочным эффектом этого является то, что вы можете выполнить GET для AnnotationRequests, чтобы увидеть документы, которые в данный момент обрабатываются. Вам решать, как долго вы хотите хранить AnnotationRequests. Может быть полезно вести полную историю того, когда они были запрошены, кем и сколько времени они заняли, или можно периодически выбрасывать их.

Вы можете проверить Уди Дахана nServiceBus.