RESTFUL風格自從被提出來就很火了，尤其是在這個移動互聯網爆發的時代...... ...
RESTFUL風格架構
WYH?
隨著前後端分離的流行，以及移動互聯網的爆發，導致後端API介面要向不同的Web端提供服務，那麼對於 API 的規範就需要有一定的要求了。這個時候 RESTFul 的優勢就體現出來了，它更簡潔，更有層次，更易於實現緩存。
此概念"表現層狀態轉換(Representational State Transfer&REST)"是Roy Thomas Fielding 博士於 2000 年在他的博士論文中提出來的一種萬維網軟體架構風格，目的是便於不同軟體/程式在網路（例如互聯網）中互相傳遞信息。表現層狀態轉換是根基於超文本傳輸協議 ( HTTP ) 之上而確定的一組約束和屬性，是一種設計提供萬維網路服務的軟體構建風格。
——維基百科
核心思想
其實REST就是對資源表現形式的轉換的一種規範，或者說是資源以某種形式進行狀態轉換。直白的講就是按照一定的規範去操作某種特定格式的數據。
規範
- 用URI定位資源
- URI由名稱組成
- 使用HTTP方法對應數據的操作
HTTP請求方法主要有七種：分別是：
GET, POST 和 HEAD方法（HTTP1.0）
OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法（HTTP1.1）
其中GET、POST 、DELETE、PUT四種請求方法在RESTFUL風格中最為常見：
| HTTP方法 | 安全性 | 冪等性 | 介面說明 |
|---|---|---|---|
| GET | 安全 | 冪等 | 獲取資源（Read） |
| POST | 不安全 | 非冪等 | 創建資源（Create） |
| PUT | 不安全 | 冪等 | 更新資源（Update） |
| DELETE | 不安全 | 冪等 | 刪除資源（Delete） |
關於URL&URI
你可能會註意到，上面提到的REST規範中，用到的是URI而不是URL。那它們之間有什麼區別呢？其實，要向弄清楚，還需要引入另一個概念——URN。
三者解釋：
- URI：Universal Resource Identifier 統一資源標誌符
- URL：Universal Resource Locator 統一資源定位符
- URN：Universal Resource Name 統一資源名稱
一張圖說明三者的關係：
可以看出，URI包含URL與URN，或者說是URL與URN的總稱。
所以：只要一個URI符合URN，我們就可以認為這個URI不是URL了，其實，關於URL與URN，大白話就是，URL可以在任意的互聯網中定位一個資源，而URN則辦不到。
url. https://www.google.com
urn. mailto:[email protected]
關於冪等性&安全性
你也許也會註意到上文提到了冪等性與安全性的概念，在這裡不做過多解釋，就按照大白話簡單說明下：
- 冪等性：當一個請求與多個同樣的請求會不會返回相同的結果
- 安全性：一個請求發出之後會不會對伺服器資源產生改變
額外：常用HTTP響應碼
| 代碼 | 含義 |
|---|---|
| 200 | （OK）- 如果現有資源已被更改 |
| 201 | （created）- 如果新資源被創建 |
| 202 | （accepted）- 已接受處理請求但尚未完成（非同步處理） |
| 301 | （Moved Permanently）- 資源的URI被更新 |
| 303 | （See Other）- 其他（如，負載均衡） |
| 400 | （bad request）- 指代壞請求 |
| 404 | （not found）- 資源不存在 |
| 406 | （not acceptable）- 服務端不支持所需表示 |
| 409 | （conflict）- 通用衝突 |
| 412 | （Precondition Failed）- 前置條件失敗（如執行條件更新時的衝突） |
| 415 | （unsupported media type）- 接受到的表示不受支持 |
| 500 | （internal server error）- 通用錯誤響應 |
| 503 | （Service Unavailable）- 服務當前無法處理請求 |
