Из руководства Microsoft по разработке API (https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design#more -информация ):
В более сложных системах может быть заманчиво предоставить URI, которые позволяют клиенту перемещаться по несколько уровней отношений, например /customers/1/orders/99/products. Тем не менее, этот уровень сложности может быть трудно поддерживать и является негибким, если отношения между ресурсами изменятся в будущем. Вместо этого постарайтесь сделать URI относительно простыми. Как только у приложения есть ссылка на ресурс, должна быть возможность использовать эту ссылку для поиска элементов, связанных с этим ресурсом. Предыдущий запрос можно заменить на URI /customers/1/orders, чтобы найти все заказы для клиента 1, а затем на /orders/99/products, чтобы найти продукты в этом заказе.
Избегайте, чтобы URI ресурсов были более сложными, чем набор / элемент /collection.
На примере Microsoft, скажем, я хочу найти все продукты клиента 1. Затем мне нужно будет сначала запросить /customers/1/orders, чтобы найти все заказы, а затем запросить отдельный заказы на /orders/{id}/products, что приводит к проблеме N + 1. Кроме того, если я хочу создать новый заказ, я должен POST до /customers/1/order или /orders с customer_id?
//2 endpoints
/customers/1/orders
/orders/{id}/products //for n orders
Или я мог бы построить все API с 1 глубиной и искать все продукты по /products/?customer_id=1
//3 endpoints
/customers
/orders
/products
Подводя итог,
, что будет лучше? Вложенный против 1 глубины, но больше конечной точки
Если вложенность лучше, на примере Microsoft, если я хочу создать новый заказ для клиента 1, следует ли мне POST до /customers/1/orders или /orders с customer_id в теле или с поддержкой обоих?