在这种情况下我应该如何设计WEB API？

Question

我正在设计一个新的 API，我怀疑它应该是一个单一的 API 还是应该被划分为最终用户类型。

例如我有以下课程

OrderClass
ProductClass
BuyerClass
SupplierClass

并且想要创建允许买家和供应商访问它的 API

我是否创建一个单一的 API，例如

CompanyAPI that uses access tokens (defining roles and types)
/api/order/orderAction [allowed for buyers, suppliers]
/api/order/orderAction2 [allowed for buyers] 
/api/order/orderAction3 [allowed for suppliers] 
/api/buyer/buyerAction [allowed for buyers, suppliers]
/api/supplier/supplierAction [allowed for suppliers]
/api/product/productAction [allowed for buyers, suppliers]

或两个旨在满足买方或供应商需求的 API？

BuyersAPI
/BuyersAPI/order/orderAction
/BuyersAPI/order/orderAction2
/BuyersAPI/buyer/buyerAction
/BuyersAPI/product/productAction 
SuppliersAPI
/SuppliersAPI/order/orderAction
/SuppliersAPI/order/orderAction3 
/SuppliersAPI/supplier/supplierAction 
/SuppliersAPI/product/productAction 

使用两个 API 的主要原因之一是文档，我不希望买家看到供应商正在获取什么信息（至少是它的结构）似乎是合乎逻辑的。

另一方面，拥有两个 API 意味着某些部分将/可能被重复/复制。

Answer 1

最大的问题是重叠。如果 95% 的 API 是共享的，而 5% 因客户端类型而异，那可能就是一个 API。如果 5% 由客户端共享，95% 由客户端共享，那么您有多个 API。在您看来，鉴于您的 API 的 RPC 特性，我倾向于严重倾向于单独的 API。它们往往比 RESTful API 增长得更快，我预计多种客户端类型的不同需求将推动这种增长。

我假设您正在使用基于注释的文档提供程序，这就是您将文档作为权衡的一部分的原因。如果您采用多 API 路线，我强烈建议非常薄的 API 层依赖于共享服务层，或者每个客户端类型的自定义服务层和共享功能的公共服务层。这应该有助于减少重复。

理论上，您可以对 API 层执行相同的技巧 - 在多个项目中定义它，并在共享项目中使用公共端点。如果端点需要从公共项目转移到客户端项目中，这可能会令人兴奋，反之亦然，因此请确保在尝试之前进行彻底的研究。

Answer 2

有一种流行的现代技术，称为micro-services。它要求您以 'per resource' 方式拆分您提供的服务。它使您将来可以轻松地平衡和扩展您的服务，但在 devops 和基础架构方面需要额外的开销。

考虑到路由，我不喜欢你们提出的两种变体。 RESTful 服务是以资源为中心的，而不是以行动为中心的。 所以在你的情况下，我最终会拥有order、product、buyer、supplier...（无论资源是什么）web-api 项目，每个项目都具有对资源的简单操作语义。

例如：

/api/orders {POST an order instance} 
/api/order {GET an order instance}
/api/order {PUT an existing instance}
...

如果我弄错了，并且提到的实体不是您案例中的资源，那么您需要重新定义架构，找到这些资源并围绕它们构建路由。无论如何，当 Web 服务变成一堆可支持/可扩展性差的方法GetCustomerCodeFromYetAnotherSetOfAttributes(...) 时，我建议不要坚持那种 SOAP 风格。

考虑到对服务的访问——我认为它与 sdlc 完全不同，因此它与路由无关。所以所有的操作都应该是一组系统用户角色的不变量。