Дизайн REST-api для постов с микросервисами

Question

У меня есть своего рода "тривиальный" вопрос о моем rest-api для постов, но я предпочитаю получить свой дизайн с самого начала.
Сообщения могут быть запрошены пользователем или google_place_id.
Без микросервисной архитектуры я бы выбрал дизайн моего REST-API следующим образом:

base_uri / GPlaces /: gplaceId / сообщений
base_uri / пользователей /: идентификатор пользователя / сообщения

При использовании микросервисов для меня более разумно иметь микросервисы "users", "posts" и "gplaces".

В этом случае мои конечные точки будут выглядеть так:

base_uri / сообщений / GPlaces /: gplaceId
base_uri / posts / users /: userId

что на самом деле не имеет смысла для меня, или:

base_uri / сообщений? Тип = by_place & gplace_id =?
base_uri / сообщения? тип = by_user & user_id =?

Желательно, чтобы я использовал первый вариант (вариант gplaces /: gplaceId / posts).

Есть ли возражения против использования другого домена в качестве первого сегмента пути в микросервисной архитектуре? (обычно base_uri / gplaces будет принадлежать gplace-api).

Answer 1

Если каждый микросервис является автономным сервисом, по одному для пользователей, сообщений, мест, тогда я думаю, что URL будут:

мест микросервис:

base_uri/:gplaceId

пользователей микросервисов:

base_uri/:userId

сообщений микросервиса:

base_uri/user/:userId
base_uri/place/:gplaceId

с учетом:

?type=by_user&user_id=? 

Тип

является избыточным, поскольку вы идентифицируете тип по второму параметру user_id или gplace_id. Я просто думаю, что кодирование того, что вам нужно в URI, является более кратким

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