Актуален ли ReST (HTTP) для широковещательной передачи данных многим клиентским приложениям?

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

Кроме того, клиентские приложения смогут взаимодействовать с системой (т.е. набор микросервисов) через ReST Открытый API.

Для широковещательной передачи данных моим первым соображением было использование MOM (ПО промежуточного слоя, ориентированное на сообщения), например AMQ.

Однако меня попросили пересмотреть это решение и предпочесть конечная точка ReST(через HTTP), чтобы предоставить API больше «Ориентирован на открытый API».

Я не большой специалист по HTTP, но мне кажется, что основными технологиями для отправки асинхронных данных с сервера на клиент являются:

  • Веб-сокет
  • ССЭ

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

  • технология HTTP, такая как SSE/WebSocket, актуальна для моих нужд

For additional information, here are a few metrics regarding the amount of data to broadcast

  • considerable amount of messages per seconde
  • responsiveness
  • more than 100 clients listening for data

Спасибо за вашу помощь и вклад

Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
0
507
1

Ответы 1

Существует множество различных определений того, что люди считают REST, а не REST, но большинство людей склонны соглашаться с тем, что с практической точки зрения и популярных передовых практик службы REST предоставляют модель данных через HTTP и ограничивают операции этой моделью данных, запрашивая состояние ресурсов. (GET) или обновление состояния ресурсов (PUT). Из этого основания вещи складываются поверх него.

То, что вы описываете, является моделью pub-sub. Хотя с академической точки зрения возможно использование концепций REST в архитектуре pub-sub, я не думаю, что это действительно то, что вы ищете здесь.

Websocket и SSE в большинстве реальных ситуаций не попадают под зонтик REST, но они могут дополнить существующую службу REST.

Если ваша цель — просто создать систему pub-sub, использующую стек технологий, с которым люди знакомы, веб-сокеты — действительно хороший выбор. Он широко доступен и работает в браузерах.

Другие вопросы по теме