这种情况下WEBAPI应该怎么设计呢？

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 意味着某些部分 would/could 是 repeated/duplicated。

Answer 1

大问题会重叠。如果您的 API 的 95% 是共享的并且 5% 因客户类型而异，那可能是一个 API。如果 5% 由客户共享，95% 由客户共享，那么您有多个 API。在您看来，考虑到您的 API 的 RPC 性质，我倾向于严重依赖于单独的 APIs。它们的增长速度往往比 RESTful API 快，我预计多种客户类型的不同需求将推动这种增长。

我假设您使用的是基于注释的文档提供程序，这就是为什么您考虑将文档作为权衡的一部分。如果您采用多个 API 路线，我强烈建议使用非常薄的 API 层，这些层取决于共享服务层，或每个客户端类型的自定义服务层和共享的公共服务层职能。这应该有助于最大程度地减少重复。

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

Answer 2

有一种流行的现代技术，叫做micro-services。它迫使你以 'per resource' 的方式拆分你提供的服务。它允许您在未来轻松平衡和扩展您的服务，但需要在开发运营和基础设施方面的额外开销。

考虑到路由，我不喜欢你们提出的两种变体。 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 服务变成一堆糟糕的 supportable/extensible 方法时，我建议不要坚持那种 SOAP 风格 GetCustomerCodeFromYetAnotherSetOfAttributes(...).

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

这种情况下WEBAPI应该怎么设计呢？

How should I design WEB API in this case?

api

api-design

asp.net-web-api