Question

我正在考虑 REST API 设计。我的数据库中有几个表。例如客户和订单。

当然 - 每个订单都有其客户（每个客户可以有多个订单）。

我决定提供这样的界面

/api/v1/Customers/      -- get list of Customers, add new Customer
/api/v1/Customers/:id:  -- get Customer with id=:id:
/api/v1/Orders/      -- get list of Orders, add new Order
/api/v1/Orders/:id:  -- get Order with id=:id:

它完美无缺。但是我的前端必须显示带有客户姓名的订单列表。使用此接口，我将不得不对 /api/v1/Orders/ 进行一次调用，然后针对前一次调用中的每条记录再次调用 /api/v1/Customer/:id:。或者对 /api/v1/Orders/ 和 /api/v1/Customers/ 执行两次调用，并在前端将它们组合起来。

看起来有点矫枉过正，这种操作应该在数据库层面进行。但是我可以/应该如何提供合适的接口？

/api/v1/OrdersWithCustomers
/api/v1/OrdersWithCustomers/:id:

看起来有点怪怪的。走的路对吗

Answer 1

很好的问题，任何 API 设计都会在这样的某个时刻触及实用的现实。

一种选择是为每个资源包括一个更大的对象图（即包括链接到每个订单的客户），但使用过滤查询参数来允许用户指定他们需要或不需要的属性。

我个人认为，对于检索资源列表时的搜索语义，或在这种情况下过滤为每个资源呈现的内容，RESTful GET 上的请求参数都适用

您的用例的另一个选择可能是研究 GraphQL 方法。

Answer 2

没有规则说您不能“扩展”从 REST API 调用返回的数据。因此，您当然可以返回一个 Order，其中包括 OrderResponseDTO 实体的所有（相关）字段 - 加上来自 Order 实体的一些可能与您的用例相关。

您的 REST API 的数据模型不必与您的基础数据库架构完全 1:1 匹配 - 它确实让您可以自由地省略某些字段，或添加一些额外的字段您的 API 的使用者会发现有用的信息。

Answer 3

你会如何在网络上做到这一点？

您有一个网站，该网站提供有关客户的文档和有关订单的文档。但是您的客户并不满意，因为在这两种文档中汇总信息太无聊且容易出错。

他们问，无聊的工作已经完成了，我们可以提供一份文件吗？

因此，您生成了一堆这些新报告，并将它们粘贴到您的 Web 服务器上，并创建链接以更轻松地在相关文档之间导航。达达。

“REST-API”是一种外观，使您的信息看起来和行为都像一个网站。您从数据库生成表示这一事实是一个实现细节，故意隐藏在“统一接口”后面。

我应该如何设计 REST API

3 个答案: