大多數關于設計 RESTful API 訪問控制的資訊都圍繞著用戶（即不同的用戶有不同的訪問級別等）。
想象一個沒有用戶概念的系統。有一堆服務器通過 RESTful API 相互通信。沒有客戶端 - 我的意思是，對于兩臺服務器之間的每次互動，其中一臺都可以被視為“客戶端”，但我的觀點是所有服務器或多或少“相等”，并且每臺服務器都可以向許多其他服務器發送請求服務器（反之亦然）。
這與傳統的 Web/移動客戶端-服務器架構非常不同。
現在，想象一下，并非所有這些服務器實際上都是 100% 相同的。有些人應該可以訪問某些 API，但不是全部。如何確保這種級別的訪問控制？
uj5u.com熱心網友回復：
讓我們將您擁有的服務器視為網路中的節點以避免混淆。當 node1 向 node2 發送請求時，在該互動中，node2 是服務器，node1 是客戶端（類似于“用戶”）。
因此，從 node2 的角度來看，如果您必須區分 client1 和 client2（可以發送請求的兩個可能的節點）每個可能訪問或可能不訪問的內容，那么強烈建議為節點2。
這意味著您將擁有鍵值對，其中鍵是方法，值是角色。
每當 client1 或 client2 請求一個方法時，您就會以某種方式確定該方法所需的角色以及 client1 和 client2 是否具有所有必要的角色。
這意味著對于 node2 的 API，每當收到請求時，都需要執行以下演算法：
APIWrapper將呼叫一個中心方法（我們暫時稱它為）APIWrapper找出客戶的角色是什么APIWrapper找出需要呼叫的角色function1，客戶端請求的函式function1如果客戶端沒有滿足任何需要的角色，則以未經授權的錯誤回應并停止該程序- 如果此階段已成功到達且沒有未經授權的錯誤，則執行
method1并將其回應傳輸給客戶端
您可能有一個角色林，也就是說，您將擁有角色樹，具體取決于訪問級別（即，您可能有一個單獨的角色來上傳 xlsx 檔案，并且您可能有一個角色來上傳任何檔案，所以，在這個如果您可能需要 xlsx 上傳，而客戶端將具有上傳任何檔案的角色，在這種情況下仍應允許客戶端執行給定的操作）。
如果您對角色的子類別有這樣的要求，那么強烈建議您
- 在 value 部分的角色映射中，您將指定角色所屬的角色樹（即檔案上傳）和該角色的級別（即 xlsx）
- 在每個角色樹中，如果存在父 P 和子 C，則意味著 P => C，即 C 將比 P 更具體，因此如果角色 P 存在，則意味著角色 C 也存在于客戶
- 每個角色都需要有一個簽名來唯一標識它在樹中的路徑，因此到達它會有 O(log(N)) 復雜度而不是 O(N)
不言而喻，分配或撤銷角色的方式需要安全且一致。
所以，這就是我們從node2的角度思考的問題。然而，node2 本身也可能是其他節點的客戶端。那時的問題類似。
但是，如果 server1 在 node1 獲得/失去一個角色，那會觸發 server1 獲得/失去其他一些服務器的角色嗎？如果是這樣，那么您還需要某種方式來同步角色，可能會定期通過 cron 作業。
最后，如果角色的定義、分配和撤銷方式能夠標準化，那就太好了。因為這樣的話，每臺服務器的配置，無論其內容如何不同，都可以使用相同的軟體進行維護，這將大大簡化管理負擔。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/426477.html