与不同订户（公司）构建REST API的最佳实践是什么？

Question

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

最佳使用方法是什么？：

1. 为每个订户（公司）构建通用API和子API，当请求到来时，我们检查请求并使用（API密钥）将其转发到子API，然后将数据检索到通用API，然后检索到客户端。 / p>

2. 我们是否应该制作单个API和许多数据库来存储每个订阅（公司）数据（因为每个公司都有大量记录，说明为什么我们建议将数据库分开以提高性能）？当请求到来时，我们验证它并根据客户端请求更改数据库连接字符串。

3. 我们应该制作一个API和一个处理所有订阅数据的大数据库吗？

您是否建议采用任何新方法来解决此问题？我们使用了Web API和MS SQL Server以及Azure Cloud。

Answer 1

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

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

此设置没有性能问题。

Answer 2

取决于交易量和数据的性质，您可以为每个公司寻找单个数据库或单独的数据库。

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

您可以在发出访问权限时使用ClientID验证。

Answer 3

我从您的问题中了解到，您需要为多个消费者（公司）提供其他API。从逻辑上讲，该公司的员工将使用您的API，员工可能是管理员，人力资源等。所以我建议您使用单个Rest API为您的消费者提供服务，为了安全起见，您必须使用OpenId。 OAuth顶部2.这将解析您的身份验证和授权。