I want to know the standard way of designing API calls URL to Microservices. I have 2 microservices Example- User, Order. APIs created will be used in my application UI and also for any third-party integration. Which Url pattern should I follow:
METHOD1: Hide internal microservice implementaion
To create user:
POST: /user (Call goes to User Service)
To get user:
GET: /user/{userId} (Call goes to User Service)
To create order for user
POST: /user/{userId}/order (Call goes to Order Service and order service internally validate user with user service)
To get user order by id
GET: /user/{userId}/order/{orderId} (Call goes to Order Service and order service internally validate user with user service)
METHOD2: Each API has details of which Microservice it belongs to
To create user:
POST: /userService/user (Call goes to User Service)
To get user:
GET: /userService/user/{userId} (Call goes to User Service)
To create order for user
POST: /orderService/order (Call goes to Order Service with userId in Request Body and order service internally validate user with user service)
To get user order by id
GET: /orderService/order/{orderId} (Call goes to Order Service with userId in Request Body and order service internally validate user with user service)
Which one is good approach, also let me know if this can be done in any other different way? Thanks in Advance.
Method1. From outside, the clients should not be able to see the difference between micro service architecture and monolith.
You do not want to reveal the details of your backend to outside, for security reasons.
But having said that, if you designed your micro services properly each micro service will deal with a certain resource(user, order). So it would look like that the each main route targets the corresponding micro service.
For a complete different solution have a look into graphql and apollo federation. I use this to wrap all my micro service API's to a single clean endpoint.