Структура полезной нагрузки запроса/ответа RabbitMQ

Question

Я разрабатываю систему, которая будет использовать RabbitMQ для запроса/ответа между приложениями.

Я привык работать с API REST и исходя из этого фона Я думал о том, как структурировать сообщения при выполнении запроса/ответа.

мне нужно структурировать, чтобы обрабатывать несколько сценариев:

• Получение/запроса данных с удаленного сервера
• Создание данных на удаленном сервере
• Работа на стороне клиента ошибки

Я планирую иметь форматирование полезной нагрузки JSON. И я думал об использовании каких-то кодов ответов, подобных HTTP (возможно, используя одни и те же коды?) И установить код ответа как свойство/заголовок сообщения.

Для получения/запроса моей идеи было иметь свойство запроса в объекте полезной нагрузки.

Но это заставило меня подумать, что я могу думать об этом слишком сильно, как API REST, и может быть лучше, более устоявшийся способ сделать это.

Я читал книгу «RabbitMQ in Action» при настройке, но я не вижу упоминания об этом. Мой google-fu также провалил меня и не дал никаких результатов.

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

Answer 1

Если вы используете RabbitMQ в сценарии запроса/ответа среди приложений, которые уже знакомы или реализованы для обработки вызовов REST, вам не нужно отклоняться от него в RabbitMQ для формата сообщения.

С вашего вопроса, я собираюсь понять, что RabbitMQ действует как промежуточный сервер между вашим приложением. Вы упомянули три сценария. Если вы берете данные и записываете данные, здесь RabbitMQ действует только как маршрутизатор между приложением, которое запрашивает получение или запись данных и приложение, которое извлекает и записывает данные. Если это так, уже существует стандартный формат сообщений, который может поддерживать обслуживающее приложение (сервер с данными). Предположим, что он еще не имеет определенного стандарта. В этом случае вы можете думать с точки зрения ожидаемого приложения в полезной нагрузке запроса. Забудьте промежуточный сервер RabbitMQ на этом этапе. Размышление о сообщениях RabbitMQ может отклонить вас от использования лучших практик.

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