Использование обмена сообщениями для записи и чтения

Question

Я работаю в Интернете, где мне приходится иметь дело только с HTTP, поэтому, пожалуйста, извините за мое невежество.

У меня есть приложение, в котором клиенты прослушивают изменения в очереди сообщений, использующей Stomp.Раньше клиенту нужно было только прослушивать соответствующие каналы на наличие сообщений, сообщающих им об изменениях на сервере, и соответствующим образом обновляться.Простые вещи.

Теперь клиент должен иметь возможность редактировать данные и отправлять эти изменения обратно на сервер.Данные на сервере уже доступны через ресурсы restful, поэтому моей первой мыслью было просто заставить REST отправлять запросы на изменение данных на сервере, но затем я начал задаваться вопросом, смогу ли я найти решение с помощью обмена сообщениями.Я мог бы просто открыть другой канал, в котором клиенты могли бы публиковать изменения, а сервер мог бы подписаться на этот канал и соответствующим образом обновляться.Реализация этого, очевидно, будет простой, но мне бы хотелось, чтобы мне заранее указали на некоторые потенциальные ловушки.

Я знаком с REST, поэтому хочу задать несколько вопросов в контексте REST:

• Могу ли я сопоставить группу очередей с глаголами REST/CRUD для каждого ресурса, т.е.itemPostQueue, itemPutQueue, itemDeleteQueue?
• А как насчет GET, как я могу запросить данные для чтения с использованием очереди?
• Что мне использовать, чтобы заменить механизм кода состояния, чтобы выявить проблемы, или я просто запускаю и забываю (глоток) или каким-то образом использую заголовки ошибок/получений в Stomp?

Любые ответы и советы будут высоко оценены.

С уважением,

Крис

Answer 1

Хотя мне не совсем понятно, почему ты должен используйте обмен сообщениями здесь, несколько мыслей:

Ты мог сопоставляется с REST на проводе, например itemPostQueue, но это, вероятно, покажется неестественным для человека, ориентированного на сообщения.Если вы используете какую-то очередь со встроенной гарантированной семантикой и однократной доставкой, тогда используйте этот механизм.В примере с корзиной для покупок вы можете отправить сообщение AddItem по сети и доверять инфраструктуре, чтобы один раз доставить его на сервер.

Нет прямого ПОЛУЧАТЬ подобная концепция здесь, в очереди сообщений.Вы можете смоделировать это с помощью пары сообщений: я отправляю вам запрос, а вы отправляете мне ответ.Это очень похоже на RPC, но еще более отделено.Итак, я отправляю вам запрос PublishCart, а затем сервер отправляет сообщение CartContents по каналу, который прослушивает клиент.

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

Одна вещь, которую действительно делает обмен сообщениями, — это существенное разделение вашего приложения.В отличие от HTTP, где ты знаешь, что что-то произошло, с очередью ты отправляешь кому-то письмо.Оно может туда попасть.Почтальон мог уронить его в снег.Собака может его съесть.Если вы не получаете ответа в течение какого-то периода времени, вы пытаетесь связаться с родственниками другими способами или, отведя аналогию, связаться с сервером.Мониторинг состояния инфраструктуры очередей, глубины очередей и т.п. приобретает дополнительную важность, поскольку они представляют собой систему, от которой вы теперь зависите.

Удачи