I am designing a Microservice application but have some difficulties with the REST API design.
Scenario: A Microservice application with the services "Customer" and "Order", and follows the "Database-per-service pattern".
The customer-service have basic endpoints to represent a customer resource like:
GET /customers, POST /customers, GET /customers/:id etc...
Problem: How to design the endpoints for the order-service, to get all orders belonging to a customer?
I've thought about different solutions but none really satisfy me.
/customers/id/orders - My problem with this solutions is the use of "customers" in a service that does not contain any data about the customers.
/orders?customerid=123 - This would work, but I dont feel that it follows the normal API design guidelines.
Does any guidelines on the subject of API design in microservice architecture exists?
IMO, you are requesting for an order so you should ask for the resource order. You are customer has no role to play as orders are not kept inside a customer resources. If anything, order has a reference to a customer. And if you are querying orders based on some attribute, they should be passed as a query parameters. So since you are asking (GET) for resource (Order) and want to filter them (based on customer in query param), the option 2 make sense. And thats how I would design it and those are my reasons to design it this way.