Microservices / REST - Как хранить ссылки на ресурсы в другом сервисе - PullRequest
0 голосов
/ 07 ноября 2018

Предполагая, что ресурс X (http://example.com/a/foo/7) из службы отдыха A должен содержать ссылку на второй ресурс Y (http://example.com/b/bar/1) из службы отдыха B.

Как можно сохранить ссылку?

В настоящее время я сохраняю весь URI (в виде строки) Y на постоянном уровне службы A. Является ли это общим / допустимым подходом? Мне кажется неправильным извлекать id (1) из URI Y, поскольку я реализовал бы предположения о структуре URI службы B в службе A. Это правильно?

Как вы решаете эту проблему?

Thx!

Ответы [ 2 ]

0 голосов
/ 08 ноября 2018

Давайте обсудим это с какой-то реальной бизнес-областью, тогда ответы будут иметь смысл.

Итак, первый пример:

X представляет объект заказа в сервисе заказов Amazon, Y обозначает клиента в отделе обслуживания клиентов.

Теперь при получении заказа от Amazon из службы заказа вы также хотите показать некоторые основные сведения о клиенте и ссылку на объект Customer, чтобы перейти на страницу сведений о клиенте.

В этом случае я хотел бы при создании заказа скопировать некоторые основные атрибуты клиента в объекте заказа (customerName, customerArea).

Также сохраните customerId, customerType. А поскольку API для извлечения клиента является Public и также доступен различным внутренним службам, Order Service выполнит обнаружение службы и создаст URL и вызов. В этих случаях, как правило, служба поддержки клиентов не прекращает поддерживать старый способ (даже если он строит новый).

Так что хранение только id - это решение.

Случай 2:

Amazon Order Entity хочет сохранить детали доставки, а партнер по доставке - это какое-то стороннее юридическое лицо, такое как DHL, тогда, если DHL предоставит URL для получения обновлений доставки заказа, в этих случаях я просто сохраню URL.

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

Хранение прямого URL имеет смысл, когда это сторонний URL.

Также, если вы можете привести определенный пример вашего бизнес-кейса, как это, мы можем обсудить лучше

0 голосов
/ 08 ноября 2018

Ссылки IMO должны храниться как есть. То, как вы получаете реальные данные из справки, должно быть не частью данных, а логикой, которая может время от времени меняться. Я буду хранить их как ссылку на внешнюю ссылку (просто для того, чтобы нарисовать картинку, эта ссылка находится вне нашего сервиса) и соединить ее с логикой для запроса данных.

URL очень изменчив и может измениться. Как правило, вы никогда не должны хранить URL-адреса в своей базе данных и должны полагаться на обнаружение службы, чтобы определить, где находится служба, даже если она находится внутри вашей собственной инфраструктуры.

Это не предположение, это контракт, который может измениться, и если это произойдет, ваш сервис будет зависимым сервисом и должен будет внести соответствующие изменения

Кроме того, по вашей логике, даже если вы сохраняете URL, ответом на него по-прежнему является контракт, которого вы оба придерживаетесь.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...