與不同的訂戶（公司）一起構建REST API的最佳實踐是什么？

Question

在具有許多訂戶（公司）的REST API的安全性，性能和維護方面，最佳的設計方法是什么？

最佳使用方法是什么？

1. 為每個訂戶（公司）構建通用API和子API，當請求到來時，我們檢查請求並將其轉發到使用（API密鑰）的子API，然后將數據檢索到通用API，然后再傳遞給客戶端。

2. 我們是否應該使用單個API和多個數據庫來存儲每個subscription（company）數據（因為每個公司都有大量記錄，所以我們建議分離數據庫以提高性能） ？ 當請求到來時，我們對其進行驗證並根據客戶端請求更改數據庫連接字符串。

3. 我們是否應該制作一個API和一個處理所有訂閱數據的大數據庫？

您是否建議任何新方法來解決此問題？ 我們使用了Web API，MS SQL Server和Azure雲。

Answer 1

過去我只有一個API，使用OAuth / JWT對API進行保護，而令牌中有一個公司ID。 收到請求時，我們從JWT讀取公司ID並在主數據庫中執行查找，該數據庫包含全局信息，例如每個公司的連接字符串。 然后，我們創建一個與公司的關聯字符串相關聯的工作單元，並且任何數據庫查找都將使用該工作單元。

這意味着您可以從一個主數據庫和一個節點數據庫開始，當節點數據庫開始超載時，您可以啟動另一個數據庫，然后向其中添加新公司或遷移現有公司以減輕壓力。 本質上，您只是在需要時向外擴展。

此設置沒有性能問題。

Answer 2

根據交易量和數據的性質，您可以選擇一個數據庫或為每個公司使用單獨的數據庫。

• 如果您具有復雜的數據模型，則選項2最好
• 我看不到選擇1的任何優勢，因為，無論如何，通用API都會為每個請求調用。

您可以在發出訪問令牌時使用ClientID驗證。

Answer 3

從您的問題中我了解到的是，您希望為多個消費者（公司）提供一個REST API。 從邏輯上說，該公司的員工將使用您的API，員工可能是admin，HR等。因此，對於這種情況，我建議您必須使用單個Rest API，以便為您的消費者提供服務並確保安全，您必須在OAuth 2的頂部。這可以為您解決身份驗證和授權。