這里的好人已經對這個話題說得夠多了。但這是我的兩分錢。
有兩種互動方式：
- 人對機(Htm)
- 機器對機器(Mtm)
機器是公共分母，表示為REST API，參與者/客戶端要么是人，要么是機器。
現在，在真正的RESTful體系結構中，無狀態的概念意味著所有相關的應用程序狀態(即客戶端狀態)都必須與每個請求一起提供。相關的意思是，無論RESTAPI需要什么來處理請求并提供適當的響應。
當我們在人機應用程序的上下文中考慮到這一點時，“基于瀏覽器的”(Browser-Based)，正如skrebel前面所指出的，這意味著在瀏覽器中運行的(Web)應用程序將需要將其狀態和相關信息與它向后端RESTAPI發出的每個請求一起發送。
考慮一下：您有一個數據/信息平臺公開了RESTAPI資產。也許您有一個處理所有數據立方體的自助BI平臺。但你希望你的(人類)客戶通過(1)網絡應用程序、(2)移動應用程序和(3)第三方應用程序訪問這些應用程序。最終，即使是連鎖的MTM也會導致HTM-右。因此，人類用戶仍然處于信息鏈的頂端。
在前兩種情況下，您有一個人機交互的案例，即人類用戶實際使用的信息。在最后一個例子中，您有一個機器程序使用RESTAPI。
認證的概念是全面適用的。您將如何設計它，以便以統一、安全的方式訪問RESTAPI？在我看來，有兩種方法：
路-1：
- 首先沒有登錄。每個請求都執行登錄。
- 客戶端發送標識參數+每個請求的特定請求參數。
- RESTAPI接受它們，掉頭，點擊用戶存儲(不管是什么)，并確認了auth。
- 如果建立了auth，則為請求提供服務；否則，拒絕使用適當的HTTP狀態代碼
- 對目錄中所有RESTAPI的每個請求重復上述內容。
路-2：
- 客戶端以一個auth請求開始。
- 登錄RESTAPI將處理所有此類請求。
- 它接受auth參數(API鍵、uid/pwd或您選擇的任何參數)，并根據用戶存儲(LDAP、AD或MySQLDB等)驗證auth。
- 如果被驗證，則創建一個auth令牌并將其交回客戶端/調用方。
- 然后，調用方將這個auth令牌+請求特定的params和每個后續請求發送到其他業務RESTAPI，直到注銷或租約到期為止。
顯然，在方法-2中，RESTAPI需要一種方法來識別和信任令牌是有效的。LoginAPI執行auth驗證，因此目錄中的其他RESTAPI需要信任“valetkey”。
當然，這意味著需要在RESTAPI之間存儲和共享auth密鑰/令牌。這個共享的、受信任的令牌存儲庫可以是本地/聯邦的，允許來自其他組織的RESTAPI相互信任。
但我離題了。
關鍵是，需要維護和共享“狀態”(關于客戶端的身份驗證狀態)，以便所有RESTAPI都能創建一個信任循環。如果我們不這樣做，這就是方法-1，我們必須接受必須對任何/所有傳入的請求執行身份驗證的行為。
執行身份驗證是一個資源密集型的過程。想象一下，針對每個傳入請求，針對用戶存儲執行SQL查詢，以檢查uid/pwd匹配?；蛘?，加密和執行哈希匹配(AWS樣式)。在架構上，我懷疑每個RESTAPI都需要使用一個通用的后端登錄服務來執行這個任務。因為，如果你不這么做，你就到處亂扔代碼。一堆爛攤子。
所以更多的層，更多的延遲。
現在，采取方式-1，并適用于HTM。你的(人類)用戶真的關心你是否必須發送uid/pwd/散列或任何與每個請求相關的內容嗎？不，只要你不打擾她，你每秒鐘都會拋出這個/登錄頁面。如果你有顧客，祝你好運。所以，您要做的是將登錄信息存儲在客戶端的某個地方，在瀏覽器中，就在開始時，并將其與每個請求一起發送。對于(人工)用戶，她已經登錄，并有一個“會話”可用。但在現實中，她每一次請求都要經過認證。
路-2也是一樣。你的(人類)用戶永遠不會注意到。所以沒有造成傷害。
如果我們向MTM申請1路呢？在這種情況下，由于它是一臺機器，我們可以通過要求它提交每一個請求的身份驗證信息來讓這個家伙感到厭煩。沒人注意你!在MTM上執行Way-2不會引起任何特殊的反應，這是一臺該死的機器。它會不在乎的！
所以，問題是什么適合你的需要。無國籍是要付出代價的。付出代價繼續前進。如果你想成為一個純粹主義者，那么也要為此付出代價，然后繼續前進。
最后，哲學并不重要。真正重要的是信息發現、展示和消費體驗。如果人們喜歡你的API，你就做好了你的工作。
