1

我们有一个应用程序将 RESTful API 暴露给 UI 以购买商品。我有一个关于 API 设计的问题。可以说应该按顺序采取以下行动

  1. 要选择购买的项目
  2. 接下来给出要送达的地址

我的问题是：我们是否应该设计一个让两个数据同时执行的 API？或者我们应该设计两个 API 调用 - 一个创建购买记录，第二个更新要交付的地址？

4

2 回答 2

2

推荐的 SOA 方法是选择粗粒度的服务，这似乎是在争论 API 调用的最小数量。

但是，从业务的角度来看，项目选择和购买以及项目交付是两个非常不同的关注点，应该是架构中的独立组件。对于项目选择，您需要考虑库存和定价等问题。对于送货地址，您需要考虑用户地址列表、地址验证、运输和税收。

这两个组件不太可能进行太多交互，除非项目 ID 和地址 ID 之间存在一些外部关联。出于这个原因，我推荐两个 API 调用。从功能上讲，这还允许您的 API 用户执行诸如更新送货地址而不重新购买商品、将账单发送到一个地址并将商品发送到另一个地址等操作。

于 2013-09-29T16:18:35.777 回答
1

当您声明您设计一个 RESTful API 时，您通常从设计资源而不是预期调用开始。稍后，可以选择包含其他资源以优化 HTTP 请求计数的资源表示。

您可能希望选择通过以下方式进行：

  1. 对项目列表资源建模（GET - 列出所有项目，POST - 允许创建项目）/items/
  2. 为地址列表资源建模 /addresses/
  3. 建模项目实例资源 /items/item/resourceId
  4. 为地址实例资源建模 /addresses/address/resourceId

现在您的所有资源都可用，您可以考虑使用模式。您的所有资源通常都是可用的，并且可以混搭。回答您的问题的可能方法是：

  1. 使用所需的地址详细信息扩展项目实例资源（粗粒度如 lreeder 所述）
  2. 将资源 /deliverydetails/ 建模为包含项目和地址的列表和实例资源，通过项目 ID 或您的用例最适合的任何内容来查询交付详细信息

希望有帮助！顺便提一句。您会自动采用面向资源的设计来遵循 SOA 方法。接口自然会适合您的业务需求，并且足够通用以支持更高级的用例。

这是一个很好的例子

于 2013-09-29T17:02:41.983 回答