Routing with micro services

Question

I’ve decided to create my project following a micro service architecture. I have a products service and a reviews service.

The products service essentially stores all information regarding a product whilst the reviews service stores reviews for a product.

I’ve decided to keep these separate from each other as I would like to scale the reviews service at some point in the future.

My products service has a single controller with a bunch of actions, the route for this service is api/products

I realized that on the reviews service I need to create an endpoint to grab all reviews of a product, but not sure what the route should be. I feel like because it’s the reviews service the routing should be named like api/reviews, but surely you’d expect the route for this action to be api/products/{id}/reviews

How should the routes be named if each service has to be independent from one another?

Answer 1

Cross Cutting Concerns

Each service should have the sqrt(0) concern for the interface of any other service excepting those it actively collaborates with. So it is natural for each service to have an Endpoint (quite likely at root, or some configurable base path). eg:

service 1: domain1\{id}   serves up a product
service 2: domain2\{id}   serves up a review

And other endpoints for various queries, etc...

That being said what you are doing is taking one Application (from the perspective of the user) and splitting it into two independent services. That is a problem. The API is a cross cutting concern.

Presentation

From the users perspective they probably want to interact in a few ways with your domain, not just with these service but perhaps the website too. Something like:

domain\                            To the Web Server
domain\api\products\{id}\reviews   To service 2
domain\api\products\               To service 1
domain\api\reviews\                To service 2

It doesn't really matter how you organise which service provides for which end point as long as it is sensible, stable, and documented. The most important being stable, the other two are to minimise your client developer frustrations, important when publishing an API.

So what you have are two or more independent services who disagree on what the API should look like, whose own API's are subject to independent change - and what you need is to present a single consistent API. It almost sounds like you need a service to present these services...

Front-End / Back-End

To make this happen you need a Reverse-Proxy, or an Application Gateway. It is the service whose responsibility it is to present a stable API. Depending on how advanced the reverse proxy/application gateway is it can:

• Pass through connections for requests matching some path
• Rewrite request content to make it sensible to the backend service (like xml->json conversion, or path manipulation)
• Rewrite response content to make it sensible to the client (like json->xml conversion or hyper link manipulation)
• Logging
• Health monitoring
• Load Balancing

Now when you add a new service, you don't have to collaborate API changes across the X other services. You need only update the gateway to direct the right API end-points and perform the right adjustments.

Removing a service is similar, update the API gateway to point to the replacement service, or to remove those end-points altogether.

Answer 2

Personally I would expect the reviews to be on domain/reviews.

But you shouldnt over think expectations. Because i won't be typing in random URIs based on what I expect. I will be checking the documentation for your api or client to aee which method I should call.

Use the path that best fits your architecture and techincal constraints and publish instructions telling people how to use the API.