在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方法。 接口将自然地满足您的业务需求和通用性，足以支持更高级的用例。

这是一个很好的例子