Как создать асинхронную систему уведомлений с использованием веб-служб RESTful?

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

Пример использования примерно следующий:

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

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

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

Ответ 1

Я могу думать о четырех подходах:

Подход Twitter: вы регистрируете клиента, а затем периодически пересылаете его с помощью GET для получения любых уведомлений.
Клиент описывает, как он хочет получать уведомление, когда он делает запрос на регистрацию. Таким образом, вы можете позволить JMS для тех, кто может справиться с этим, и вернуться к электронной почте или аналогичным для тех, которые не могут.
Возьмите URL-адрес во время запроса на регистрацию и POST обратно каждому клиенту индивидуально, когда у вас есть уведомление. Вряд ли Pub/Sub, но эффект будет аналогичным. Конечно, вы предполагаете, что Клиент слушал эти уведомления и реализовал свой Клиент в соответствии с вашими спецификациями.
Купить IBM WebSphere MQ (MQSeries). Лучший продукт IBM. Не REST, но это отлично подходит для многоплатформенной интеграции, как это.

Ответ 2

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

То есть у вас есть один URL (/Signup.htm, скажем), который принимает информацию о клиенте (если это необходимо, идентификатор объекта для мониторинга) и возвращает настроенный URL (/Monitor/XYZPDQ), где XYZPDQ является UUID, созданный для этого конкретного клиента. Клиент может опросить этот настроенный URL на некоторый интервал, и он получит уведомление, если произойдет обновление.

Если вам неинтересно, кто такой клиент (и не хотят создавать так много UUID), у вас могут быть только отдельные URL-адреса RESTful для каждого объекта, который может потребоваться для мониторинга, а URL-адрес "регистрации" просто верните правильный.

Как говорит Джон Сондерс, вы не можете сделать более прямое публикацию/подписку через HTTP.

Ответ 3

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

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

Ответ 4

Если опрос неприемлем, я бы рассмотрел использование веб-сокетов (например, см. здесь). Хотя, честно говоря, мне нравится идея предложенная пользователем189423 тип многостраничного контента или chunked transfer-encoding.