在SOA体系结构中，应该由单个API完成所有操作，还是将API拆分为多个操作

我们有一个应用程序，它将RESTful API公开给用户界面，用于购买物品。我有一个关于API设计的问题。让我们假设应该按顺序采取以下行动

要选择购买的项目

下一步给出要发送到的地址

---

我的问题是：我们是否应该设计一个API，让两个数据同时执行这两个任务？或者我们应该设计两个API调用—一个用于创建购买记录，另一个用于更新要发送到的地址？

建议的SOA方法是选择粗粒度服务，这似乎是为了证明API调用的最小数量

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

---

除了项目id和地址id之间的一些外部关联之外，这两个组件不太可能进行太多交互。因此，我建议使用两个API调用。从功能上讲，这还允许API用户在不重新购买项目的情况下更新交付地址、将账单发送到一个地址、将项目发送到另一个地址等等。

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

您可能希望选择以下方式继续：

对项目列表资源进行建模（GET-列出所有项目，POST-允许创建项目）/项目/

对地址列表资源/地址进行建模/

对项实例资源/items/item/resourceId进行建模

对地址实例资源/addresses/address/resourceId进行建模

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

使用所需的地址详细信息扩展项实例资源（如lreeder所述的粗粒度）

对资源/deliverydetails/as列表和包含项目和地址的实例资源进行建模，使deliverydetails按项目id或任何最适合您的用例进行查询

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

---

一个有趣的问题是，获取已购买商品的交付地址的路径是什么？在这种情况下，与订单相关的商品也应该绑定到“地址”资源。我将设计一个包含指向我们需要的地址资源的链接的“已购买商品资源/purchased/resourceId”已生成/addressess/address/resourceId。因此，您可以使用类似链接扩展的概念，对购买的项目资源进行类似于/items/item/id/addresses/address/id的建模，从而允许将资源与扩展的项目或地址资源一起发送。