REST или очередь сообщений в многоуровневой гетерогенной системе?

9

Я разрабатываю REST API для трехуровневой системы, такой как: Client application-> Front-end API cloud server-> user's home API server (Home).

Homeявляется домашним устройством и должен поддерживать соединение Front-endчерез Websocket или длительный опрос (это первое место, где мы нарушаем REST. В дальнейшем это становится еще хуже) . Front-endв основном туннелирует Clientзапросы к Homeсоединению и обрабатывает некоторые вызовы сама. Иногда Homeотправляет уведомления Client.

Front-endи Homeимеют в основном один и тот же API; Clientможет быть подключение к Homeнапрямую через локальную сеть. В этом случае Homeнеобходимо зарегистрировать некоторые Clientдействия на Front-endсебя.

Плюсы для REST в этой системе:

  • ОТДЫХ читается человеком;
  • REST имеет четко определенное отображение глаголов (например, CRUD), существительных и кодов ответов на объекты протокола;
  • Он работает по HTTP и передает все возможные прокси;

REST контрастами являются:

  • Нам нужен не только стиль общения запрос-ответ, но и публикация-подписка;
  • Коды ошибок HTTP могут быть недостаточны для обработки трехуровневых ошибок связи; Front-endможет вернуться 202 Acceptedк какому-либо асинхронному вызову только для того, чтобы узнать, что необходимое Homeсоединение разорвано и должно было быть 503;
  • Homeнеобходимо отправлять сообщения Client. Clientпридется опрашивать Front-endили поддерживать связь.

Мы рассматриваем WAMP / Autobahn через Websocket, чтобы получить функциональность публикации / подписки, когда меня поразило, что это уже похоже на очередь сообщений.

Стоит ли оценивать своего рода очередь сообщений как транспорт?

Похоже, что очереди сообщений:

  • Мне нужно самому определить глаголы CRUD и коды ошибок на уровне сообщений.
  • Я читал кое-что о «более высокой стоимости обслуживания», но что это значит?

Насколько серьезны эти соображения?

Виктор Сергиенко
источник
1
Почему у вас есть облачный сервер в смеси? Похоже, все, что он делает, это перенаправление, что заставляет меня думать, что он должен правдоподобно жить на той же машине, что и домашний сервер ...
Джимми Хоффа,
3
Когда вы анализируете очереди сообщений, обратите внимание, что большинство из них оптимизированы для частных локальных сетей: низкая задержка, контролируемые клиенты, защищенная сеть и т. д. Выставление очереди в Интернет может быть огромной проблемой безопасности.
Хавьер
@Jimmy Hoffaдействительный момент, спасибо. Это верно, но не полностью. Это общая база данных, хранилище и так далее. @Javierспасибо, это хорошая часть ответа.
Виктор Сергиенко
Домашний сервер предназначен для работы в доме какого-то пользователя и на стороне клиента в облаке? Дом соединяется с внешним интерфейсом, и клиент отправляет сообщения домой через внешний интерфейс. Если я правильно понимаю ваш замысел, я могу дать божественный ответ.
Майкл Браун
@Mike Brownточно. Пожалуйста, сделай.
Виктор Сергиенко

Ответы:

5

Если у вас есть возможность подключения, используйте очередь сообщений - хотя вы должны определить свои собственные протоколы (вряд ли это трудная задача!) Для отправки сообщений определенной структуры и формата.

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

Если у вас есть проблемы с подключением через Интернет, только с портом 80 и http и «однонаправленной» связью, то, вероятно, лучше всего использовать систему в стиле REST. Отправляйте и опрашивайте или получайте веб-сокет для данных обратного вызова, но, как правило, разработчик вашей системы будет клиент / сервер. Если у вас есть возможность получить подключение, то системы обмена сообщениями - это хорошо.

Я бы выбрал ZeroMQ для системы обмена сообщениями, достаточно настраиваемой, чтобы ее можно было использовать в любых сценариях, включая отказоустойчивые. Я не уверен, что это работает через http, хотя.

gbjbaanb
источник
Спасибо. Что я нашел после @Javierкомментария: ØMQ, похоже, не поддерживает само шифрование atm: zeromq.org/area:faq#toc8, хотя RabbitMQ делает: rabbitmq.com/ssl.html
Виктор Сергиенко,
Я не знаю, есть ли у меня связь. Homeявляется домашним устройством пользователя и Clientпредставляет собой смартфон через Wi-Fi или 3G. Одна большая часть вопроса - мое незнание методов обхода NAT.
Виктор Сергиенко
5

Похоже, автобан прекрасно вписывается в то, что вы пытаетесь сделать. Есть и другие доступные инструменты. Ознакомьтесь с сервисной шиной Windows Azure (в которой есть клиентские платформы для Java, .NET, PHP, Python, NodeJS и Ruby).

Пока встроенные сообщения об отдыхе полезны. Вы обнаружите, что ваше приложение перерастет основные операции CRUD. Например, если ваша заявка была банковской системой. Вместо

Обновить Acct 54321 Баланс = Баланс - 20.00 Обновить Acct 98765 Баланс = Баланс + 20.00

Вы, вероятно, хотели бы одно сообщение, как

Перевод 20,00 со счета 54321 на счет 98765

Лучше, чтобы вы обнаружили это препятствие с REST сейчас, а не позже. Ознакомьтесь с Event Centric от Greg Young, в котором рассказывается, как создать более богатую модель для обмена сообщениями в вашем приложении.

Майкл Браун
источник
Большое спасибо. Действительно, мы могли бы перерасти CRUD, хотя не очень скоро, наша область теперь довольно проста. Кстати, книга еще не опубликована, и я пытаюсь найти материалы в блоге Грега ... Я думаю, хорошо, что для этого не нужно использовать технологию Microsoft.
Виктор Сергиенко
Подождите, пока его книга еще не вышла ... он так долго об этом говорил ... звучит как другой технический автор, которого я знаю. : ">
Майкл Браун
1
Для записи, подход REST будет иметь ресурс Transfer, который вы создаете. Или даже TransferRequest, который может пройти или нет. REST становится сложным в некоторых случаях, но это не один из них.
Яцек Горгонь