Network

[Network] 09. REST & RESTful

 · 2 mins read

  • Representational State Transfer 是一種網路架構風格。
  • REST 是設計風格而不是標準，REST 通常基於使用 HTTP，URI，和 XML 以及 HTML 這些現有的廣泛流行的協議和標準。
    • 資源是由 URI 來指定。
    • 對資源的操作包括獲取、創建、修改和刪除資源，這些操作正好對應 HTTP 協議提供的 GET、POST、PUT 和 DELETE 方法。
    • 通過操作資源的表現形式來操作資源。
    • 資源的表現形式則是 XML 或者 HTML，取決於讀者是機器還是人，是消費 web 服務的客戶軟件還是web 瀏覽器。當然也可以是任何其他的格式。


REST & RESTful 比較

一般 API 的 interface

  獲取使用者資料 /getAllUsers
  獲取使用者資料 /getUser/1
  新增使用者資料 /createUser
  更新使用者資料 /updateUser/1
  刪除使用者資料 /deleteUser/1

RESTful API 風格的

  獲取使用者資料 /GET /users
  獲取使用者資料 /GET /user/1
  新增使用者資料 /POST /user
  更新使用者資料 /PUT /user/1
  刪除使用者資料 /DELETE /user/1

  • 差異是在於 RESTful API 充分地使用了 HTTP protocol (GET/POST/PUT/DELETE)，達到：

    1. 以直觀簡潔的資源 URI。
    2. 並且善用 HTTP Verb。
    3. 達到對資源的操作。
    4. 並使用 Web 所接受的資料類型：JSON, XML, YAML 等，最常見的是 JSON。


優點

  • 瀏覽器即可以作為 client 端。
  • 可以更高效地利用 cache 來達到更快的回應速度。
  • 界面與資料分離。
  • 節省伺服器的計算資源。
  • 可重用，web/android/ios 都可以用。

RESTful 的要求

  • client - server 架構。
  • 分層系統。
  • 利用快取機制增加效能：
    • server-side：在 GET 資源時，若該資源並沒有被變更，就可以利用 cache 機制減少 query，並且加快回應速度。
    • client-side：透過 client 端 cache 記錄 cache 版本。
    • 若向 server 要求資源時發現 server 最新版與 cache 相同，則 client 端直接取用本地資源即可，不需要再做一次查詢。
    • 省機器運算及流量 = 省錢。
  • 通訊協定具有無狀態性：
    • 不能讓兩隻 API 做同一個動作。
    • 假設完成轉賬手續必須先 call A 再 call B 的話，若做完 A 後斷線導致 B 無法執行，後續要處理 A -> B 的方式會很麻煩。
    • 且不應該假設伺服器知道目前的狀態。
    • 因此設計出來的 API 不能有狀態性。
  • 統一界面：
    • 使用 HTTP Verb：GET/POST/PUT/DELETE。

什麼時候需要打造 RESTful API?

  • 當有數組資源要被多種不同平台使用時，就需要打造 RESTful API（例如，有 Android/ iOS / Web 要對同一 table 做存取時）。


restful api 安全驗證

RESTful Api 是基於 Http 協議的 Api，是無狀態傳輸，所以只要和用戶身份有關的請求都會帶上身份認證信息。（很多時候客戶端事先並不知道某個 api，後期會不會加入身份判斷，所以我們一般都會選擇每個請求都會帶上認證信息，如果有的話。）

使用 Http Basic Authentication

  • 帳號密碼直接暴露在請求中，危險性高

      GET /auth/basic/ HTTP/1.1
  Host: xxxxx
  Authorization: Basic em1rOjEyMzQ1Ng==

使用 Cookie + Session

  • 當客戶端登錄完畢之後，給客戶端返回一個 cookie。
  • 服務器端控制該 session 的有效期， 每次請求都帶上該值，然後服務器端做驗證。
  • 退出之後，客戶端通知服務端端銷毀 session ，自身銷毀 cookie 。
  • 但是如果抓包獲取到 cookie ，就能任意偽造請求了。
  • 危險性高。

使用 Api Key + Security Key + Sign

​

  1. 用戶登錄返回一個 api_key 和 security_key ；
  2. 客戶端將 security_key 存在客戶端；
  3. 當要發送請求之前，通過 function2 加密方法，把如圖所示的五個值一起加密，得到一個 sign ；
  4. 發送請求的時候，則將除去 security_key 之外的值，以及sign 一起發送給服務器端；
  5. 服務器端首先驗證時間戳是否有效，比如是服務器時間戳 5 分鐘之前的請求視為無效；(在一定程度上屏蔽了一些無效的請求)
  6. 然後根據 api_key 驗證 sercurity_key ；
  7. 最後驗證 sign 。

防止惡意的 api ddos 攻擊

  • 表示這個接口在某一時間段內，該授權用戶調用該接口的最大次數為 5000 次，該時間段內還剩餘 4999次。當然，這樣的驗證加上之後，在代碼的執行效率上肯定會有所影響。

      X-RateLimit-Limit: 5000
  X-RateLimit-Remaining: 4999


ref :

  • https://ithelp.ithome.com.tw/users/20091343/ironman/762
  • https://blog.csdn.net/weixin_40907382/article/details/79971738
  • https://progressbar.tw/posts/53