使用不同订阅者（公司）构建 REST API 的最佳实践是什么？答案

【问题标题】：What is the best practices for building REST API with different subscribers (companies)?使用不同订阅者（公司）构建 REST API 的最佳实践是什么？
【发布时间】：2017-08-01 04:48:52
【问题描述】：

对于拥有众多订阅者（公司）的 REST API，在安全性、性能和维护方面的最佳设计方法是什么？

最好的使用方法是什么？：

为每个订阅者（公司）构建通用 API 和子 API，当请求到来时，我们检查请求并使用（API 密钥）将其转发到子 API，然后将数据检索到通用 API，然后再到客户端。
我们是否应该制作单个 API 和多个数据库来存储每个订阅（公司）数据（因为每个公司都有大量记录，所以我们建议分离数据库以提高性能）？当请求到来时，我们验证它并根据客户端请求更改数据库连接字符串。
我们是否应该创建一个 API 和一个大数据库来处理所有订阅数据？

您有什么新方法可以解决这个问题吗？我们使用了 Web API 和 MS SQL Server 和 Azure Cloud。

【问题讨论】：

标签： sql-server rest api azure asp.net-web-api

【解决方案1】：

过去我有一个 API，该 API 使用 OAuth/JWT 在我们拥有公司 ID 的令牌中进行保护。当收到请求时，我们从 JWT 读取公司 ID 并在主数据库中执行查找，该数据库保存全局信息，例如每个公司的连接字符串。然后，我们创建一个工作单元，该单元具有与之关联的公司连接字符串，并且任何数据库查找都使用它。

这意味着您可以从一个主数据库和一个节点数据库开始，当节点数据库开始过载时，您可以启动另一个数据库，然后添加新公司或转移现有公司以减轻压力。本质上，您只是在需要时进行扩展。

此设置没有性能问题。

【讨论】：

【解决方案2】：

根据交易量和数据性质，您可以为每个公司选择单个数据库或单独的数据库。

如果您有复杂的数据模型，选项 2 将是最好的
我认为选择选项 1 没有任何优势，因为无论如何通用 API 都会为每个请求调用。

您可以在颁发访问令牌时使用 ClientID 验证。

【讨论】：

在性能方面：在您更改数据库连接字符串的每个请求中是否良好。
无论如何都会为每个请求建立新的数据库连接。连接字符串将是它的参数。

【解决方案3】：

我从您的问题中了解到，您需要一个适用于多个消费者（公司）的休息 API。从逻辑上讲，该公司的员工将使用您的 API，员工可能是管理员、人力资源等。因此，我对这种情况的建议是，您必须使用单个 Rest API 为您的消费者提供服务，并且为了安全起见，您必须在OAuth 2 的顶部。这将为您解决身份验证和授权问题。

【讨论】：

您可以参考login.microsoftonline.com。同样的方式，您可以要求您的消费者使用他们的 Active Directory 凭据登录。