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层依赖于共享服务层，或者每个客户端类型的自定义服务层以及共享功能的公共服务层。这应该有助于减少重复。

理论上，您可以对API层执行相同的操作 - 在多个项目中定义它，并在共享项目中使用公共端点。如果端点需要从公共端转移到客户端项目中，反之亦然，那么这可能会令人兴奋，所以在尝试之前一定要仔细研究。

Answer 2

有一种流行的现代技术，称为micro-services。并且它要求您以每资源＆＃39; 的方式拆分您提供的服务。它允许您在将来轻松平衡和扩展您的服务，但在开发和基础设施方面需要额外的开销。

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

E.g：

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

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

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

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

2 个答案: