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.
