本系列文的環境狀態，可點擊此連結後花園環境參考

REST 是為了走更長遠的路建出更好的後花園，所以今天文章就先到這了，在下先休息了...Zzzzz

圖片來源：Guys, REST APIs are not Databases

咦...等等這個 REST 好像不是那個休息的意思，所以我好像該回來繼續...？

REST (全名 Representational State Transfer 表現層狀態轉換) ，並不是一種標準或協定，簡單地說 REST 是一種軟體架構風格，以英文形容詞來說，美麗 (beauty) 的事物可以稱為 Beautiful，同理可證：設計為 REST 的系統，我們就稱為 RESTful。

1. HTTP 協定中，有哪些 request method

HTTP實際上是將動詞應用於名詞的通用協議。

構成三元素，request line、request header、message body

• POST：(Creaate)新增一項資料。
• GET：(Read)取得(想要的服務)的資料或是狀態。（safe & idempotent）
• PUT：(Update)利用更新的方式於"指定位置"新增一項資料。 （idempotent）
• DELETE：(Delete)指定資料刪除。 （idempotent）
• HEAD：參照，取得HTTP標頭、meta資訊
• PATCH：更新，在現有的資料欄位中，增加或部分更新一筆新的資料。

舉個例來說：
GET：取得型錄，瞭解可以買的花種、栽種時機、適宜土壤。
POST / PUT：表達要購買的花種及數量，跟店家下訂單。
PATCH / PUT ：下完單後，想跟店家換不同的花，或加購其他花卉。
DELETE：取消訂單。

可以看到PUT感覺好像很厲害，兼具了兩種功能，但這要去參照下RFC5789。

PUT在新增上(idempotent)無論同筆資料做多少次，回傳結果都會一樣，不似POST就是直接再做一筆新的或是秀"錯誤"說已有同筆資料。

PUT除新增外亦可做更新請求，假設使用PUT 做更新，不管是既有的資料或是覆蓋原先的資料，都會利用覆蓋的方式去更新，而PATCH則可以針對已經存在的資料欄位去做部分更新，非屬於 idempotent 的操作。

所以 PUT 沒有很厲害，還是要看清楚自己的需求去使用他，否則會GG的。

2. RESTful API

REST簡化開發，其架構遵循CRUD原則，該原則告訴我們對於資源(包括網絡資源)只需要四種行為：創建、獲取、更新和刪除，就可以完成相關的操作和處理。您可以通過統一資源標識符（Universal Resource Identifier，URI）來識別和定位資源，並且針對這些資源而執行的操作是通過 HTTP 規範定義的。其核心操作爲GET、PUT、POST、DELETE。

由於REST強制所有的操作都必須是stateless的，這就沒有上下文的約束，如果做分布式，集群都不需要考慮上下文和會話保持的問題。極大的提高系統的可伸縮性。

三概念：非同步、冪等性、重試（Retry)

四原則：

1. HTTP造成的無狀態，可在伺服器端無法保有中途資料時，進行請求重整處理。
2. URI提供位址具體性，可指定特定資源(URI)
3. HTTP方法提供一致性介面，可進行整合性的控制
4. XML、JSON提供資源之間的連接性，可進行回應資料為觸發點的事件處理。

REST 提出了一些設計概念和準則：

• 將程式的狀態和功能拆解成資源Resource
• 每個獨立的url可以對應到相對的resource
• 可以使用put get patch這種動作對resource操作
• 看到網址，就可以定義出對應到的資源
• 搭配動作可以對應到對於該資源的處理方式

RESTful API相關參考資源：
❁ How I Explained REST to My Wife
❁ [筆記] REST 到底是什麼
❁ 淺談 REST 軟體架構風格 (Part.I) - 從了解 REST 到設計 RESTful！
❁ 休息(REST)式架構? 寧靜式(RESTful)的Web API是現在的潮流？
❁ 什麼是 REST? RESTful?
❁ 淺談 SOAP Webserver 與 Restful Webserver 區別
❁ 簡明RESTful API設計要點