Вложенные ресурсы и микросервисы: как избежать монолитов? - PullRequest
Новая
       22

Вложенные ресурсы и микросервисы: как избежать монолитов?

0 голосов
/ 09 апреля 2020

Я хочу получить адресные данные человека.

В соответствии со спецификацией REST у меня должен быть следующий путь: 

GET /person/<person id>/address/<address id>

Теперь, предположим, что я хочу получить адреса c электронов, у меня будет: 

GET /person/<person id>/address/<address id>/electronic/<elec id>

И так далее. Хотя REST-метод хорош, он может привести к монолитному подходу c, поскольку генератор openapi (но также и человек, реализующий его) создаст один-единственный микросервис, обрабатывающий данные нескольких типов.

Что может быть другой способ справиться с этим сценарием? Я думал о:

1-обращение логи c

GET /addresses/<person id>/<address id>
GET /electronicAddresses/<person id>/<address id>/<electronic address>

2 - использовать параметры заголовка / строки запроса и оставить для отдельных служб 

GET /addresses/<address id>?person_id=
GET /electronicAddress/<elec id>?person_id

Могу ли я дать несколько практических указаний? Я чувствую, что внутренний ресурсный подход в конце концов взорвется ...

1 Ответ

1 голос
/ 09 апреля 2020

Если я вас правильно понял, вы хотите декомпозировать свой API и отобразить его на архитектуру микросервиса, как в случае с address и person.

Если это так, рассмотрите address и person как нечто независимое, поэтому будет две службы: Person service и Address service. Которые будут иметь следующие API: 

GET /persons/{person_id}
GET /addresses/{address_id}

Теперь вопрос, как получить адрес какого-то человека, поскольку все API адресов не имеют параметров запроса, связанных с личностью. Ответ: сделать два вызова API .

Итак, при первом запросе клиент извлекает данные о людях по person_id, которые должны содержать некоторую ссылку на адресную сущность, например: address_id. Теперь со вторым запросом клиент может получить персональный адрес путем address_id анализа из личных данных.

...