背景介紹
RESTful是一種很常見的網頁API服務,說起來就是按REST(Representational State Transfer)的作者 Roy Thomas Fielding博士於2000年發表的論文中發表的一種架構風格,比起他的前輩SOAP(Simple Object Access Protocol)來說,他的模式較為簡潔,因此許多著名的Web API都會支援,如:Google、Amazon API等。而符合REST規則設計的系統就叫做RESTful。
RESTful的格式說明
RESTful最常使用在各種Web Service中,透過URI的方式,由客戶端發送要求,伺服器再回傳資料。
※要求資料時:使用URI,將資料放在HTTP的BODY
※返回資料時:可使用 HTML、XML、JSON或其他各種格式
基本的URI的核心語法如下:
表示取得的資源為複數時:
https://www.website.com/resources/表示取得的資源為1個時:
https://www.website.com/resources/100
然而,一般存取資料的CRUD原則我們會需要處理新增(Create)、讀取(Read)、更新(Update)、刪除(Delete)等,因此實際做檔案發送時,要再搭配常見的HTTP的方法如:GET、POST、PUT、DELETE來做資料的存取,建議的用法如下幾種:
以用戶(users)為例:列表式取得所有用戶的資訊
GET https://www.website.com/users/
新增一筆用戶資訊,通常會返回此用戶資訊的資源代號(如:ID)
POST https://www.website.com/users/
使用一批用戶資訊,替換掉所有的用戶資訊
PUT https://www.website.com/users/
刪除所有用戶資訊
DELETE https://www.website.com/users/查詢指定ID的用戶資訊
GET https://www.website.com/users/100
根據指定的用戶ID,增加一筆用戶資訊
POST https://www.website.com/users/100
根據指定的用戶ID,替換現有的用戶資訊。如果該ID不存在,就改為新增一筆新的用戶資訊
PUT https://www.website.com/users/100
根據指定的用戶ID,刪除指定的用戶資訊
DELETE https://www.website.com/users/100
送出以上命令後,伺服器會帶狀態碼並且將資料返回給客戶端,常見的狀態碼有:200 OK 、400 Bad Request 、500 Internal Server Error等。
RESTful架構約束
RESTful主要是由六個架構約束定義而成,如果不符合以下任ㄧ約束原則,就不能算是一個RESTful架構
- Client–server architecture主從式架構
總是由用戶端(主)去發送請求,且伺服器端(從)總是等待用戶發送來的請求,根據請求回應資料給用戶端。 - Statelessness無狀態協議
每一個請求都視為獨立,因此伺服器端無需記憶先前請求的任何資訊。 - Cacheability可快取
伺服器回應的內容可被客戶端或是其他中介快取,以加速重複取得資料的效能。 - Layered system分層系統
允許伺服器端的中間層對請求進行回應,客戶端無法知道當前是否連到最底層伺服器,可確保一定程度的安全性。 - Uniform interface 統一介面
組件之間的通訊必須是統一化的規則,降低通訊的複雜度。 - Code on demand (optional) 支援按需程式碼 (可選)
可支援下載一段可執行的程式碼,並在客戶端執行,提高了可擴充性。
開發重點
實務上要使用RESTful的話,需注意一些重點
- 一定要使用HTTPS協議,且加入安全碼的驗證,確保連線安全性
- 取名資源時只能用名詞,且要使用複數,例如:/accounts/
- 如果需要設計查詢條件,可參考此寫法:/books?categories=17&year=2019
- 實務上要異動多筆資料時,可能會比較麻煩。例如想刪除2,4會變成發送兩筆:「DELETE /items/2」、「DELETE /items/4」,其實不必要。
也是可以把參數打包成JSON/XML放到傳送的內文裡面的。
總結
由於RESTful的特性,讓呼叫API非常便利,通常制定好變數後,幾乎就可以知道怎麼呼叫了,無狀態的特性也讓開發時省去許多麻煩。總結一句:看名詞,就知道要存取什麼內容、看使用的方法,就知道要做什麼處理、看結果的狀態碼,就知道成功或失敗。以上就是一點小小心得紀錄,謝謝觀看。