REST API设计：我们何时应该在Uri中使用关联资源？

Question

We have simple e-commerce website where we have several products. Currently, each product has "Place order" button.

When user clicks on this button, we show user a form to fill Name, Mobile number and address. We don't support any monetary transaction. Once user fills this form, the order is saved to database. The order table has OrderId, ProductId, UserName, UserMobile.

We are designing API to save the user order. Should we have association b/w product and order while designing this?

For example URI to save the user order should be like:

1. POST /api/products/1/lead/ - The request body has user information ie name,mobile,address. OR
2. POST /api/lead/ - The request body has "PRODUCT ID" and user information ie name,mobile,address.

I am confused whether productId should be in request URI or in the request body? How do we make such decision?

Answer 1

Given that

• you're first navigating to a product, before actually placing the order
• the product id has nothing in common with the UserInformation model that you're posting

I'd go with the first option: POST /api/products/1/lead/

Answer 2

I would always go with a more shallow route for representing resources, just for the sake of simplicity. No, a nested route isn't complicated or anything, but I've seen nesting go really far. So I would keep it as shallow as possible unless...

1) You plan on having more than one thing that can have a lead. For example, you can have a lead on a product:

api/products/1/lead

or a lead on a managed service that you all provide or something (I'm reaching right now):

api/managed_services/2/lead

You could pass that info in the body always, but I imagine it would become a little cumbersome to base what resource to create based on what properties were defined in the json.

2) You plan on breaking out that route and having it go to a different service eventually. Maybe this app will have to scale substantially and a ton of users will be hitting this route moreso than any other endpoint in the system. It's a lot easier to redirect all requests to a different microservice based on the url starting with api/products than it would be redirect based on the request body.

But honestly, I don't think it matters too much. As long as it's easy for your clients to consume.