Question

摘自Microsoft的API设计指南（https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design#more-information）：

在更复杂的系统中，提供URI使客户端能够浏览多个级别的关系（例如/customers/1/orders/99/products）可能很诱人。但是，如果将来资源之间的关系发生变化，则这种复杂性级别将很难维护，并且变得不灵活。相反，请尝试使URI保持相对简单。一旦应用程序引用了资源，就应该可以使用该引用来查找与该资源有关的项目。可以将上述查询替换为URI /customers/1/orders来查找客户1的所有订单，然后/orders/99/products来查找此订单中的产品。

避免要求资源URI比collection / item / collection更复杂。

以微软的示例为例，我想查找客户1的所有产品。然后，我需要先查询/customers/1/orders来查找所有订单，然后查询个人订单依据 { {1}}属于N + 1问题。另外，如果我想创建新订单，是否应该/orders/{id}/products到POST或/customers/1/order到/orders？

customer_id

或者我可以用1深度构建所有API，然后按//2 endpoints /customers/1/orders /orders/{id}/products //for n orders

搜索所有产品

/products/?customer_id=1

总结一下，

哪种方法更好？嵌套vs 1depth，但端点更多
如果嵌套更好，以微软为例，如果我想为客户1创建新订单，我应该将{{1} //3 endpoints /customers /orders /products到POST还是/customers/1/orders }}还是两者都支持？

Answer 1

从REST API设计角度来看，两种方法都可以。您应该根据用例进行设计，以提高开发人员的体验：

如果在客户环境中创建订单更直观，请选择一种嵌套方法。
如果创建订单并发送客户ID作为订单对象的属性更为直观，请选择其他方法。

您甚至可以同时使用这两种方法，因为API只是与服务进行通信的接口（就像GUI，但出于m2m的目的）。

API URI设计嵌套vs查询字符串

1 个答案: