POST在服務器新建一個資源
PUT在服務器更新資源（客戶端提供改變後的完整資源）
PATCH在服務器更新資源（客戶端提供改變的屬性）
DELETE從服務器刪除資源
HEAD獲取資源的源數據
OPTION獲取信息關於資源的那些屬性是客戶端可以改變的
接口的安全性
選https協議代替http協議這樣，避免明文傳輸數據對一些開放的接口做數字簽名
對有登錄操作的接口，先通過登錄獲取訪問的令牌，之後訪問其他需要登錄的接口
通過攜帶這個令牌進行訪問。
登錄認證機制中session和jwt對比
session的登錄原理：客戶端（client）提交用戶名密碼（或驗證碼）給服務端(server)，服務端校驗通過後，服務端會生成身份認證相關的session數據,服務端將session數據保存在文件或者內存中，並且將session_id返
回給客戶端，客戶端將返回的session_id保存在cookie中。此後客戶端請求服務端時都會在cookie中攜帶session_id。
服務端通過校驗session信息是否存在，如果存在判斷用戶是否處於登錄狀態以及用戶具有的權限。通過校驗就返回該有的
數據，沒通過校驗返回登錄頁。
session的優勢和劣勢
優勢：
1. session可以主動清除
2. session保存在服務端相對安全
3.結合cookie使用較為靈活兼容性好
劣勢：
1. cookie+ session在跨域場景下表現不好
2.如果是分佈式部署，需要多機器共享session機制，實現方法可將session存儲到數據庫或者redis
中，這樣查詢session信息時需要進行數據庫的操作
3.基於cookie的機制很容易被CSRF攻擊
jwt的登錄原理：客戶端（client）提交用戶名密碼（或驗證碼）給服務端(server)，服務端校驗通過後，將用戶的id和其它信息做為JWT playload(負載)，將其與頭部分別進行Base64編碼拼接後簽名，形成一個JWT,形成的JWT就是形同，lll.zzz.xxx的字符串。後端將JWT字符串作為登錄成功的返回結果，返回給前端。前端可以將返回結果保存在localStorge或sessionStorage上，退出登錄前刪除保存的JWT即可。前端在每次請求時將JWT放在http header中的Authorization位（解決XSS和XSRF攻擊）。後端檢查是否存在，如果存在驗證JWT的有效性。例如檢查簽名是否正確，檢查token是否過期檢查token的接受方是否是自己（可選）驗證通過後，後端使用JWT中包含的用戶信息進行其他的邏輯操作，返回相應的結果。
jwt和session的區別
session的狀態是存儲在服務端的，客戶端只存儲session_id ,而token的狀態存儲在客戶端
（因為信息全部放在客戶端所以需要密碼學的方法進行簽名和加密）分佈式系統中session共享是一個問題，session存在服務端，隨著用戶數量增多，會大幅降低服務端的性能在多個域名下，會存在跨域問題，安全性方面cookie保存在本地，容易被人利用進行CSRF攻擊
沒有留言:
張貼留言