REST API и обмен сообщениями

У меня есть система, которая предоставляет API REST с богатым набором конечных точек CRUD для управления различными ресурсами. API REST также используется интерфейсным приложением, которое выполняет вызовы с помощью Ajax.

Я хотел бы сделать некоторые из этих вызовов асинхронной и добавить надежности.

очевидным выбором кажется брокер сообщений (ActiveMQ, RabbitMQ и т. д...).

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

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

будет ли полный ESB лучшим вариантом для этого случая использования?

10
api esb messagebroker rest

3 ответов

Если я понимаю ваш вопрос, вы хотели бы "зарегистрировать" конечную точку API в качестве подписчика, чтобы она могла получать сообщения, отправленные в заданную очередь.

Я не думаю, что брокер сообщений может быть настроен для этого.

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

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

4

IMO @EligioEleuterioFontana у вас есть непонимание роли of:

  • RESTful Api
  • брокер сообщений

Это две разные подсистемы, которые предоставляют разные услуги.

теперь давайте объясним их роли относительно ваших требований:

  • у вас есть клиенты (настольные браузеры, браузеры мобильных телефонов или приложения), которые должны получить / push-данные система. (Предположение из упоминания REST API).
  • запросы от клиентов используют HTTP / HTTPS (это часть REST API вашего требования).
  • любые данные, которые нажимаются, вы хотите сделать это более отзывчивым, быстрым, надежным.

Если я правильно понял, то я бы ответил на него как:

  • все клиенты должны отправлять запросы в REST API, потому что это делает больше, чем просто CRUD. Api также обрабатывает такие вещи, как безопасность (аутентификация и авторизация), кэширование, возможно, даже дросселирование запросов и т. д.

  • REST API всегда должен быть передним концом для клиентов, так как это также "скрывает" подсистемы, которые использует API. Пользователи никогда не должны видеть / знать о любом из ваших вариантов подсистемы (например. какую БД вы используете. Вы кэшируете? если да, то чем? п.)

  • брокеры сообщений отлично подходят для разгрузки работы, которая была запрошена теперь и работу позже. Есть куча способов, которыми это можно сделать (очереди или pub/sub и т. д.), Но дело в том, что это решение, которое клиенты никогда не должны видеть или знать.

  • MB также отлично подходят для устойчивости (как вы отметили). Если что-то не удается, сообщение в очереди будет повторно предпринято после времени "x"... так далее. (нет, я не собираюсь упоминать ядовитые очереди, очередь мертвых писем и т. д.).

вы можете иметь некоторые конечные точки Api, которые являются синхронными. Конечно! Затем есть другие, которые используют некоторую возможную согласованность (т. е. для этого запроса, я разберусь с ним позже (даже если позже через 5 секунд) и просто верну ответ клиенту, сказав: "спасибо! получил его! я скоро это сделаю") ... это асинхронный рабочий процесс, который вам нужен.

конечные точки Api должны быть простыми, краткими и, надеюсь, довольно стабильными. То, что вы делаете за кулисами, когда вы меняете вещи, надеюсь, будет скрыто от клиентов. Это включает использование брокер сообщений.

в любом случае, это мой взгляд на то, как я вижу REST Api и брокеров сообщений и как они связаны друг с другом.

3

возможно, стоит заглянуть в Google Cloud sub / pub? - https://cloud.google.com/pubsub/docs/overview

1