在SOA架构中，单个API应该执行所有操作，或者应将API拆分为多个操作

Question

我们有一个应用程序，它将RESTful API暴露给用于购买项目的UI。我对API设计有疑问。让我们说应该按顺序采取以下行动

1. 选择购买的商品
2. 接下来提供要发送到
的地址

我的问题是：我们是否应该设计一个API来同时获取两个数据？或者我们应该设计两个API调用 - 一个用于创建购买记录，另一个用于更新要传递到的地址？

Answer 1

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

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

除了项ID和地址id之间的某些外部关联之外，这两个组件不太可能相互作用。出于这个原因，我建议两个API调用。从功能上讲，这也可以让您的API用户在不重新购买商品的情况下更新送货地址，将帐单发送到一个地址，将商品发送到另一个地址等等。

Answer 2

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

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

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

现在您可以使用所有资源，您可以考虑使用模式。您的所有资源都是一般可用的，可以将其混淆。 回答问题的可能方法是：

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

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

Here is a good example