背景介紹
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非常便利，通常制定好變數後，幾乎就可以知道怎麼呼叫了，無狀態的特性也讓開發時省去許多麻煩。總結一句：看名詞，就知道要存取什麼內容、看使用的方法，就知道要做什麼處理、看結果的狀態碼，就知道成功或失敗。以上就是一點小小心得紀錄，謝謝觀看。
