CODEWITHSUNDEEP
restmicroservices
Trace
Trace

Reputation: 18889

Design REST-api for posts with microservices

I have a sort of "trivial" question about my rest-api for posts but I prefer to get my design right from the start.
Posts can be requested by user, or by google_place_id.
Without a microservice architecture I would choose to design my REST-api like this:

base_uri/gplaces/:gplaceId/posts
base_uri/users/:userId/posts

When using microservices it makes more sense for me to have a microservice "users", "posts" and "gplaces".

In this case, my endpoints would either look like this:

base_uri/posts/gplaces/:gplaceId
base_uri/posts/users/:userId

which doesn't really make sense to me, or:

base_uri/posts?type=by_place&gplace_id=?
base_uri/posts?type=by_user&user_id=?

Preferrably I would use the first option though (the variant gplaces/:gplaceId/posts).

Is there any objection against using another domain as the first path segment in a microservice architecture? (usually base_uri/gplaces would belong to the gplace-api).

Upvotes: 0

Views: 203

Answers (1)

codebrane
codebrane

Reputation: 4640

If each microservice is a standalone service, one each for users, posts, places then I would think the urls would be:

places microservice:

base_uri/:gplaceId

users microservice:

base_uri/:userId

posts microservice:

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

considering:

?type=by_user&user_id=?

type is redundant as you're identifying the type by the second param user_id or gplace_id. I just think encoding what you need in the uri is more concise

Each microservice has an implicit contract. To return users, places, or posts so any stuff in the url beyond what is required to get that information is irrelevant.

Upvotes: 0

Related Questions