Restful
REST是設計風格而不是标準。是指用戶端和伺服器的互動形式。我們需要關注的重點是如何設計REST風格的網絡接口。
- REST的特點：
- 具象的(目标)。一般指表現層，要表現的對象就是資源。比如，用戶端通路伺服器，擷取的資料就是資源。比如文字、圖檔、音視訊等。
- 表現（目标實體）：資源的表現形式。txt格式、html格式、json格式、jpg格式等。浏覽器通過URL确定資源的位置，但是需要在HTTP請求頭中，用Accept和Content-Type字段指定，這兩個字段是對資源表現的描述。
- 狀态轉換（動作）：用戶端和伺服器互動的過程。在這個過程中，一定會有資料和狀态的轉化，這種轉化叫做狀态轉換。其中，GET表示擷取資源，POST表示建立資源，PUT表示更新資源，DELETE表示删除資源。HTTP協定中最常用的就是這四種操作方式。
- RESTful架構：
- 每個URL代表一種資源；
- 用戶端和伺服器之間，傳遞這種資源的某種表現層；
- 用戶端通過四個http動詞，對伺服器資源進行操作，實作表現層狀态轉換。
如何設計符合RESTful風格的API：
一 、域名：
将api部署在專用域名下：
http://api.example.com
或者将api放在主域名下：
http://www.example.com/api/ 二、 版本
将API的版本号放在url中。
http://www.example.com/api/v1.0
三、 路徑
路徑表示API的具體網址。每個網址代表一種資源。 資源作為網址，網址中不能有動詞隻能有名詞，一般名詞要與資料庫的表名對應。而且名詞要使用複數。
正确示例： http://www.example.com/api/v1.0/goods
錯誤示例： http://www.example.com/app/getgoods # 包含動詞
四、 使用标準的HTTP方法
對于資源的具體操作類型，由HTTP動詞表示。 常用的HTTP動詞有四個。
GET SELECT ：從伺服器擷取資源。
POST CREATE ：在伺服器建立資源。
PUT UPDATE ：在伺服器更新資源。
DELETE DELETE ：從伺服器删除資源。
示例：
#擷取指定商品的資訊
GET http://www.example.com/goods/ID
#建立商品的資訊
POST http://www.example.com/goods
#更新指定商品的資訊
PUT http://www.example.com/goods/ID
#删除指定商品的資訊
DELETE http://www.example.com/goods/ID 五、 過濾資訊
如果資源資料較多，伺服器不能将所有資料一次全部傳回給用戶端。API應該提供參數，過濾傳回結果。 執行個體：
#指定傳回資料的數量
http://www.example.com/goods?limit=10
#指定傳回資料的開始位置
http://www.example.com/goods?offset=10
#指定第幾頁，以及每頁資料的數量
http://www.example.com/goods?page=2&per_page=20 六、 狀态碼（前後端分離的開發都要用到狀态碼）
伺服器向使用者傳回的狀态碼和提示資訊，常用的有：
200 OK ：伺服器成功傳回使用者請求的資料
201 CREATED ：使用者建立或修改資料成功。
202 Accepted：表示請求已進入背景排隊。
400 INVALID REQUEST ：使用者發出的請求有錯誤。
401 Unauthorized ：使用者沒有權限。
403 Forbidden ：通路被禁止。
404 NOT FOUND ：請求針對的是不存在的記錄。
406 Not Acceptable ：使用者請求的的格式不正确。
500 INTERNAL SERVER ERROR ：伺服器發生錯誤。 七、 自定義錯誤資訊
一般來說，伺服器傳回的錯誤資訊，以鍵值對的形式傳回。
{
error:'Invalid API KEY'
} 八、 響應結果
針對不同結果，伺服器向用戶端傳回的結果應符合以下規範。
#傳回商品清單
GET http://www.example.com/goods
#傳回單個商品
GET http://www.example.com/goods/cup
#傳回新生成的商品
POST http://www.example.com/goods
#傳回一個空文檔
DELETE http://www.example.com/goods 九、 使用連接配接關聯相關資源
在傳回響應結果時提供連結其他API的方法，使用戶端很友善的擷取相關聯的資訊。
十、 其他
伺服器傳回的資料格式，應該盡量使用JSON 前後端分離的優點
1. pc/app/pad 多端适應
2. SPA開發模式的開始流行
3. 前後端開發職責不清
4. 前端一直配合後端，能力受限
5. 開發效率問題，前後端互相等待
6. 背景開發語言和模闆高度耦合，導緻開發語言依賴嚴重
前後端分離的缺點
1. 前後端學習門檻增加（前端要處理的資料變多了，後端傳遞資料要滿足新的規範）
2. 資料依賴導緻文檔重要性增加
3. 前端工作量加大
4. SEO的難度加大
5. 後端開發模式遷移增加成本（之前依賴模闆開發的項目）