Что такое RESTful способ мониторинга ресурса REST на предмет изменений?

Question

Если есть ресурс REST, который я хочу отслеживать на предмет изменений или модификаций других клиентов, каков наилучший (и наиболее RESTful) способ сделать это?

Одна из идей, которые у меня были для этого, заключается в предоставлении конкретных ресурсов, которые будут поддерживать соединение открытым, а не возвращаться немедленно, если ресурс (пока) не существует. Например, с учетом ресурса:

/game/17/playerToMove

«GET» на этом ресурсе может сказать мне, что настала очередь моего оппонента двигаться. Вместо того, чтобы постоянно опрашивать этот ресурс, чтобы узнать, когда наступил мой ход, я мог бы отметить номер хода (скажем, 5) и попытаться получить следующий ход:

/game/17/move/5

В "нормальной" REST-модели кажется, что запрос GET для этого URL вернет ошибку 404 (не найдена). Однако, если вместо этого сервер оставлял соединение открытым до тех пор, пока мой оппонент не выполнил свой ход, т.е.

PUT /game/17/move/5

тогда сервер может вернуть содержимое, которое мой оппонент поместил в этот ресурс. Это обеспечит меня необходимыми данными, а также уведомлением о том, что мой оппонент переехал, не требуя опроса.

Такая схема RESTful? Или это нарушает какой-то принцип REST?

Answer 1

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

Вы бы запросили /game/17/move/5, и сервер не будет отправлять какие-либо данные, пока не будет завершен ход 5. Если соединение обрывается или вы получаете тайм-аут, вы просто переподключаетесь, пока не получите действительный ответ.

Преимущество в том, что это очень быстро - как только на сервере появятся новые данные, клиент получит их. Он также устойчив к разрыву соединений и работает, если клиент некоторое время отключается (вы можете запросить /game/17/move/5 через час после его перемещения и мгновенно получить данные, затем перейти на move/6/ и т. Д.)

Проблема с длительным опросом заключается в том, что каждый «опрос» связывает серверный поток, который быстро разбивает серверы, такие как Apache (поскольку у него заканчиваются рабочие потоки, поэтому он не может принимать другие запросы). Вам нужен специализированный веб-сервер для обслуживания запросов с длинным опросом. Модуль Python twisted («движок событий, управляемый событиями») отлично подходит для этого, но он больше работает, чем обычный опрос ..

В ответ на ваш комментарий о Jetty / Tomcat у меня нет никакого опыта работы с Java, но, похоже, они оба используют аналогичную систему пула рабочих потоков с Apache, поэтому у него будет та же проблема. Я нашел этот пост , который, кажется, решает именно эту проблему (для Tomcat)

Answer 2

Я бы предложил 404, если предполагаемый клиент - веб-браузер, так как поддержание открытого соединения может активно блокировать запросы браузера в клиенте к тому же домену. Как часто опрашивать клиента, зависит от клиента.

Answer 3

Я нашел в этой статье , предлагающей новый HTTP-заголовок "When-Modified-After", который, по сути, делает то же самое - сервер ожидает и сохраняет соединение открытым, пока ресурс не будет изменен.

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