Подтвердить что ты не робот

Стиль взаимодействия с событиями в REST

В настоящее время я борюсь с проблемой дизайна, связанной с REST. Для приложения, которое я разрабатываю, необходимо отправить события, а также поддерживать стиль взаимодействия pub/sub. Я не могу придумать дизайн, чтобы обеспечить этот стиль взаимодействия, не нарушая ограничение RESTs "Безграничное взаимодействие". Я не против опроса, поскольку некоторые люди кажутся (опрос сосет), но мое приложение требует основанного на событиях и паба/подстрока взаимодействия (опрос не является для меня вариантом). Итак, мой вопрос:

  • Могу ли я создать приложение RESTful, которое поддерживает события на основе событий и pub/sub взаимодействия без нарушения REST-contraint?
  • Стиль REST подходит для такого типа взаимодействия?
4b9b3361

ОТВЕТЫ

Ответ 1

Я бы рекомендовал Распределенный шаблон наблюдателя Дунканом Крэггом как хорошее прочитанное (бит трудно получить, но стоит усилий).

Как показали другие, вероятно, вам нужно будет использовать опрос, но, как вы правильно говорите, абоненты могут зарегистрировать свой собственный интерес (POST для создания подписки). Если вы рассматриваете подписку как свой собственный ресурс, договор между издателем и подписчиком, то я бы не рассматривал его как нарушение ограничений REST (см. Состояние и безгражданство на стр. 217 RESTful Web Services для разницы между состоянием приложения и ресурса)

Ответ 2

Здесь обсуждается тема Роя.

Ответ 3

Я предполагаю, что вы имеете в виду сервер должен уведомлять клиентов о событиях. Я не понимаю, как здесь важны конкретные технологии: вы столкнетесь с теми же проблемами и должны выбрать решение из того же пула, независимо от использования веб-служб REST, SOAP или других альтернатив.

Основной вопрос: может ли ваш сервер инициировать подключения? В дополнение к этому, могут ли клиенты прослушивать порт? Если это так, клиент регистрирует (sub), а сервер уведомляет о событиях (pub). Как операция регистрации, так и события уведомления могут быть RESTful.

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

И, конечно, опрос может быть RESTful.

Ответ 4

Я не вижу причин, по которым интерфейсы RESTful не должны поддерживать события.

Это нужно сделать с помощью опроса, заметьте; и это было бы правдой, даже если бы вы использовали SOAP.

Пока ваши веб-серверы обязательно должны оставаться без гражданства, у вас, вероятно, есть DB где-то на задней панели. Вы можете использовать эту БД для обработки подписки на события, добавив таблицу подписки.

Ответ 5

Просто быстрая проверка ограничений REST:

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

Из исследования Fielding:

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

Btw. система на основе событий, вероятно, нарушит большинство ограничений. Трудно определить такие вещи, как hypermedia the engine of application state без клиентов (так как другое имя application state есть client state) и гиперссылки (поскольку они не имеют смысла в pub/sub) и т.д....

В любом случае интересный вопрос о том, как создать систему на основе событий, несколько похожую на REST. Я думаю, вам следует публиковать самоописательные сообщения, содержащие RDF, но это только подсказка. Опрос может быть жизнеспособным решением, но если бы я был вами, я бы не попытался заставить REST на основе событий...

обновление 2016.05.15.

Насколько я понимаю архитектуру клиент-сервер - Fielding описывает здесь и здесь в своей диссертации - всегда использует связь REQ/REP. Клиент отправляет запрос и отвечает служба REST. Если вы хотите иметь что-то вроде PUB/SUB без нарушения ограничения клиент-сервер, единственный способ сделать это - использование опроса. Если вы не хотите использовать опрос, то ofc. вы можете использовать службу REST и службу websocket вместе, это не запрещено...

Ответ 6

Webhooks - это ответ на эту проблему. Они допускают события, не нарушая принципов REST.