REST和RESTful的理解
REST
REST 是Roy Thomas Fielding提出的互聯網軟件的架構原則，定名爲REST，即Representational State Transfer的縮寫。翻譯是"表現層狀態轉化"。
RESTful
RESTful是一種風格。Restful風格一般用來描述各種API，符合這種風格的API被稱爲 RESTful API。
RESTful API 設計指南
REST系統特徵
https://blog.csdn.net/qq_21383435/article/details/80032375
客戶-服務器（Client-Server），提供服務的服務器和使用服務的客戶需要被隔離對待。
無狀態（Stateless），來自客戶的每一個請求必須包含服務器處理該請求所需的所有信息。換句話說，服務器端不能存儲來自某個客戶的某個請求中的信息，並在該客戶的其他請求中使用。
可緩存（Cachable），服務器必須讓客戶知道請求是否可以被緩存。（Ross：更詳細解釋請參考 理解本真的REST架構風格 以及 StackOverflow 的這個問題 中對緩存的解釋。）
分層系統（Layered System），服務器和客戶之間的通信必須被這樣標準化：允許服務器和客戶之間的中間層（Ross：代理，網關等）可以代替服務器對客戶的請求進行迴應，而且這些對客戶來說不需要特別支持。
統一接口（Uniform Interface），客戶和服務器之間通信的方法必須是統一化的。（Ross：GET,POST,PUT.DELETE, etc）
支持按需代碼（Code-On-Demand，可選），服務器可以提供一些代碼或者腳本（Ross：Javascrpt，flash，etc）並在客戶的運行環境中執行。這條準則是這些準則中唯一不必必須滿足的一條。（Ross：比如客戶可以在客戶端下載腳本生成密碼訪問服務器。）
理解REST
http://www.ruanyifeng.com/blog/2011/09/restful.html?bsh_bid=1717507328
資源（Resources）
REST 是面向資源的，這個概念非常重要，而資源是通過 URI 進行暴露。
REST的名稱"表現層狀態轉化"中，省略了主語。“表現層"其實指的是"資源”（Resources）的"表現層"。
所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
所謂"上網"，就是與互聯網上一系列的"資源"互動，調用它的URI。
表現層（Representation）
“資源"是一種信息實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層”（Representation）。
比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以採用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現。
URI只代表資源的實體，不代表它的形式。嚴格地說，有些網址最後的".html"後綴名是不必要的，因爲這個後綴名錶示格式，屬於"表現層"範疇，而URI應該只代表"資源"的位置。它的具體表現形式，應該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段纔是對"表現層"的描述。
狀態轉移（State Transfer）
訪問一個網站，就代表了客戶端和服務器的一個互動過程。在這個過程中，勢必涉及到數據和狀態的變化。
互聯網通信協議HTTP協議，是一個無狀態協議。這意味着，所有的狀態都保存在服務器端。因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。
客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議裏面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
統一接口（Uniform Interface）
REST 要求，必須通過統一的接口來對資源執行各種操作。對於每個資源只能執行一組有限的操作。以 HTTP/1.1 協議爲例，HTTP/1.1 協議定義了一個操作資源的統一接口，主要包括以下內容：
7 個 HTTP 方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
HTTP 頭信息（可自定義）
HTTP 響應狀態代碼（可自定義）
一套標準的內容協商機制
一套標準的緩存機制
一套標準的客戶端身份認證機制
REST 還要求，對於資源執行的操作，其操作語義必須由 HTTP 消息體之前的部分完全表達，不能將操作語義封裝在 HTTP 消息體內部。這樣做是爲了提高交互的可見性，以便於通信鏈的中間組件實現緩存、安全審計等等功能
超文本驅動（Hypertext Driven）
“超文本驅動”又名“將超媒體作爲應用狀態的引擎”（Hypermedia As The Engine Of Application State，來自 Fielding 博士論文中的一句話，縮寫爲 HATEOAS）。將 Web 應用看作是一個由很多狀態（應用狀態）組成的有限狀態機。資源之間通過超鏈接相互關聯，超鏈接既代表資源之間的關係，也代表可執行的狀態遷移。在超媒體之中不僅僅包含數據，還包含了狀態遷移的語義。以超媒體作爲引擎，驅動 Web 應用的狀態遷移。通過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時通過解析超媒體發現的，而不是事先定義的。從面向服務的角度看，超媒體定義了服務器所提供服務的協議。客戶端應該依賴的是超媒體的狀態遷移語義，而不應該對於是否存在某個 URI 或 URI 的某種特殊構造方式作出假設。一切都有可能變化，只有超媒體的狀態遷移語義能夠長期保持穩定。
綜述
綜合上面的解釋，我們總結一下什麼是RESTful架構：
（1）每一個URI代表一種資源；
（2）客戶端和服務器之間，傳遞這種資源的某種表現層；
（3）客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現"表現層狀態轉化"。
誤區
RESTful架構有一些典型的設計誤區。
最常見的一種設計錯誤，就是URI包含動詞。因爲"資源"表示一種實體，所以應該是名詞，URI不應該有動詞，動詞應該放在HTTP協議中。
舉例來說，某個URI是/posts/show/1，其中show是動詞，這個URI就設計錯了，正確的寫法應該是/posts/1，然後用GET方法表示show。
如果某些動作是HTTP動詞表示不了的，你就應該把動作做成一種資源。比如網上匯款，從賬戶1向賬戶2匯款500元，錯誤的URI是：
POST /accounts/1/transfer/500/to/2
正確的寫法是把動詞transfer改成名詞transaction，資源不能是動詞，但是可以是一種服務：
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
另一個設計誤區，就是在URI中加入版本號：
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
http://www.example.com/app/2.0/foo
因爲不同的版本，可以理解成同一種資源的不同表現形式，所以應該採用同一個URI。版本號可以在HTTP請求頭信息的Accept字段中進行區分（參見Versioning REST Services）：
Accept: vnd.example-com.foo+json; version=1.0
Accept: vnd.example-com.foo+json; version=1.1
Accept: vnd.example-com.foo+json; version=2.0