REST API one-to-many, many-to-many call design

I have been thinking about the design of REST API recently. Common CRUD application REST is relatively simple and clear. Most search results have the design concept of REST API. In a nutshell, URL represents resources, HTTP Method represents what to do, HTTP The response status code represents the result of doing something, such as:

Get /users/2
Response 404

Represents the User whose request ID is 2, and returns 404 to represent that the resource was not found.

https://www.zhihu.com/question/28570307 The top-voted answer also solves some problems involved in designing rest APIs, such as the difficulty of denominalizing certain verbs, which involves business abstraction and part-of-speech conversion. In addition, for example, there are two parts of speech such as search. In fact, it can be used as part of the URL when it is designed. This is already reflected in the github API:

https://api.github.com/
"repository_search_url": "https://api.github.com/search/repositories?q={query}{&page,per_page,sort,order}",

Similar to login, although it is mentioned that it is operating a session, in practical applications, it is generally not handled by rest. If /login is used as the endpoint, everyone does not think that there is a big problem.

More complex problems are encountered in business systems, including

• 1. One-to-many, many-to-many rest API design, including create, update
• 2. The circular serialization problem of two-way binding.

Here first record the handling of the problem I have seen for 1.

Generally speaking, this kind of association is divided into two cases:
[list]

One situation is that the entity of multiple parties cannot exist without the entity of one party, or the entity of multiple parties cannot be obtained directly, for example:

Everyone has multiple education records, and education records generally do not need to be used directly, but are obtained from the individual as a starting point. The URL is as follows:

GET /persons/{PERSON_ID}/edu-histories

Another situation is that both the multi-party entity and the unilateral entity exist independently, but they are related. For example, orders and commodities, at this time, multiple APIs are required.

Get a single orderGET /orders/{order_id}
Get a single productGET /products/{product_id}
Get all products of an order GET /orders/{order_id}/productsGet
all orders associated with a productGET /products/{product_id }/orders

to create this kind of association can be achieved by POST/PUT/PATCH, just add the associated entity in the body. The specific implementation is also discussed in stackoverflow which method should be more in line with the specification. Everyone mentions PATCH. In practical applications, you can adjust whether your web server supports PATCH or not.

In this case, the entity should be returned separately as far as possible, and the associated entity should not be returned, such as getting the order, and the associated product will not be returned directly. A defect caused by this is that it needs to be called multiple times by the client to return all the results.
[/list]


This defect is actually the third layer of the original design concept of RestAPI - mentioned by hateoas, that is, the result sent back by each restAPI may not only be the current one, it should also include other related The link referenced by the object is just like when we visit a URL, the URL will not only return us the content, but also provide us with other related hyperlinks. Only after Hateoas can be considered truly Restful.

Another implementation is to treat this relationship as a class of resources, and the URL is directly represented by the relationship:

GET /order-product-relationship
[{"orderId":1,"productId":2},{"orderId":1,"productId":3}]

to be continued