REST 是一種應用架構風格，不是一種標準，是面向資源架構（ROA)風格，與具體技術平臺無關，REST架構的應用未必創建在Web之上，與之對應的是傳統的Web Service 採用的面向操做的RPC架構風格。html
1、基礎概念前端
一、Web算法
爲咱們提供獲取和操做網絡資源的方式，資源包括文字、圖片、音頻、視頻；核心體如今三個方面，HTTP、超文本、超媒體，HTTP爲網絡訪問的標準協議，超文本和超媒體，規範了網絡信息的表現形式，利用「連接」在相關資源節點間穿針引線結成一張非線性網，即Web。數據庫
二、網絡協議json
(1)、IP協議跨域
處於網絡層，無連接的網絡協議，傳輸不可靠且無序，數據完整性不能保證。瀏覽器
- 不可靠性，即不能保證發送出去的數據報文成功到達目的地。
- 無序，即每次數據報文處理都是獨立的。
- 數據不完整性，接收方沒有根據報文段的校驗和來檢查數據在傳輸過程當中是否被篡改。
(2)、TCP協議緩存
位於網絡層之上的傳輸層，基於鏈接的傳輸協議，解決了IP協議不可靠性，無序性，不完整性三個問題。數據交換雙方在在數據報文傳輸前先創建一個雙工鏈接，雙方均可以用它來發送數據，在報文傳輸結束後關閉鏈接。安全
- 可靠性，藉助「接收確認」和「超時重傳」 機制來實現，發送方有個緩衝區，用來存放發送出去但還未確認的保文，超過指定時限會重發，接收到確認消息就在緩衝區刪除。
- 有序性，報文編號機制，每一個數據報文都有個編號，其體現了報文的順序，接收方接收到一個報文後，根據其編號先確認其以前編號的報文都接收了，才往應用層提交報文數據，判斷標準是其記錄一個上次成功遞交給應用層的報文編號，若是這次接收報文的編號和上次是連續的說明是有序的，不然說明以前還有報文未接收。接收方也有個緩衝區，用來存放接收但不能嚮應用層提交的保文，等以前發送的全部報文都接收到以後，按序號順序往應用層提交報文，再從緩衝區中把其刪除。另外，重複的報文會被丟棄，判斷重 復的標準是，報文的序號小於最後遞交給應用層的報文編號或者添加到緩衝區的報文編號。
- 數據完整性，報文段有個16位的校驗和（Checksum）,接收方能夠根據它來確認數據在傳輸過程當中是否被篡改。
- 報文不丟失，藉助「流量控制」機制，發送和接收方緩衝區大小不一致會致使發送後的報文會丟失，若是發送方緩衝區比接收方大，其實根據緩衝區大小來發送報文的，由於緩衝區存放了發送的並且未接收的，接收方緩衝區滿了後，不能處理後續接收的報文，因此接收方會及時通知發送方緩衝區剩餘大小，發送方根據其來控制流量。
(3)、HTTP協議服務器
位於傳輸層之上的應用層，其基於傳輸層的TCP可靠傳輸協議，提供了可靠數據傳輸的保障。是一種無狀態的網絡協議，採用簡單的「請求/響應」消息交換模式，不會保存屢次消息交換的會話狀態，每次消息交換都是相互獨立的，開始於請求發送，止於響應接
收，每次消息交換都是一次完整的事物。
IP協議根據IP地址定位數據目的地，TCP協議利用端口標識應用程序，應用程序間通信須要指定IP地址和端口。
三、資源
(1)、定義
寄宿於Web(服務器)、經過HTTP協議獲取或操做的「事物「，能夠是磁盤上的文件、數據庫裏的記錄，算法計算出的結果，可使具體的事物，也能夠是抽象的流程。
(2)、標識
可操做資源應該具備一個或多個惟一標識。標識的類型能夠採用GUID，可是URI是達成共識的公認標準。URL和URN都是URI的一種表現形式。
(3)、URL
統一資源定位符，用來定義資源的惟一標識、位置、獲取方式（協議，如HTTP）。
http://www.myhost.com/employees/001
001號員工資源的惟一標識，位置在www.myhost.com服務器上，經過HTTP協議獲取
四、媒體類型
資源是一種數據，其承載了某種信息(內容含義，好比部門全部員工)，相同的信息能夠用不一樣數據形態或數據格式來展示，這種數據格式稱爲媒體類型，好比相同的部門員工，能夠用XML格式，也能夠用JSON格式來展現。
媒體類型又稱MIME類型，經常使用的媒體類型有，text/html,text/xml,text/json,image/gif,audio/mp4,video/mp4.
五、HTTP方法
資源用URI來標識，對資源的操做類型經過Http方法來指定。常見方法有如下幾種：
- Get：獲取資源。
- Head：獲取描述資源的元數據信息。
- Option：探測請求，肯定某個目標地址的真實請求應該具備怎麼樣的約束，如採用怎麼樣的Http方法或必須攜帶怎麼的自定義報頭，而後根據其約束髮送符合條件的請求。「跨域資源」的預檢請求採用的就是Options方法。
- Post：添加一個新資源
- Put：添加或修改一個資源，存在就修改，不然添加，這裏的修改是完整修改
- Patch：部分修改，補丁的意思
- Delete：刪除資源
六、HTTP響應狀態碼
- 1XX：請求已被接受，並須繼續處理，100-199
- 2XX：請求被成功處理， 200-299
- 3XX：重定向，須要客戶端採起進一步的操做才能完成請求， 300-399
- 4XX：客戶端錯誤，因客戶端發生錯誤而妨礙了服務器的處理， 400-499
- 5XX：服務端錯誤， 500-599
七、HTTP報文
分請求報文和響應報文，內容都是包含，起始行、報頭集合（空行表示結束）、主題內容，如
- 請求報文
GET http://www.myhost.com/employees/001 HTTP/1.1 起始行
Accept：text/html,application/xml... 報頭集合
...
空行
空 主體內容
- 響應報文
HTTP/1.1 200 OK 起始行
Content-Type：text/html;charset=utf-8 報頭集合
....
空行
<!DOCTYPE... 響應主題內容
八、超媒體/超文本
超文本是與其它數據有關聯(Links)的數據。包含與其餘文檔連接的文檔；選擇連接時自動顯示第二個文檔。
超文本可利用引用連接其餘不一樣類型（內含聲音、圖片、動畫）的文件，這些具備多媒體操做的超文本，稱爲超媒體（HyperMedia），意指多媒體超文本（Multimedia Hypertext），即以多媒體的方式呈現相關文件信息。
超媒體的核心是利用「連接」將相關的信息結成一個非線性的網。
九、REST(表現/應用狀態轉換)
REST定位爲「分佈式超媒體應用」的架構風格。
應用狀態即WEB應用的客戶端狀態。
資源在瀏覽器中以超媒體的形式呈現，經過單擊超媒體中的連接能夠獲取其餘相關資源或對當前資源進行相應處理，獲取的資源或者針對資源處理的響應一樣以超媒體形式再次呈如今瀏覽器上。
藉助於超媒體這種特殊資源呈現方式，應用狀態的轉換體現爲瀏覽器中呈現資源的轉換，應用狀態變爲了可呈現的狀態，應用狀態的轉換變成了可呈現的狀態轉換，即REST。
2、RESTful Web API 特性
對於多個應用採用的架構，咱們只能說其中一個比其餘的更具備REST風格。如下是ROA架構的Web API應該具有的基本特徵，是指導方針。
一、URI標識資源
URI具備標誌性、可讀性、可尋址性。可表示單個資源，也能夠表示多個資源的集合。
http://www.myhost.com/employees/001 編號爲001的員工
http://www.myhost.com/sales/2017/12/03 2017年12月3號的銷售額
http://www.myhost.com/orders/2017/q4 2017年第四季度的訂單（資源集合）
二、使用連接關聯相關資源
資源通常不是單獨存在，與其餘資源有某種關聯，經過超文本/超媒體文檔中的連接關聯相關資源；咱們是用URL來標識資源的，文檔中的連接採用URL地址來連接到其餘資源，其可使資源地址，也能夠是對資源的操做連接。好比一份XML文檔中，包含一些其餘資源的引用。客戶端獲取該文檔在瀏覽器展示，並根據文檔中引用生成一些連接，這些連接地址都是Web API 地址，供用戶操做.
三、使用統一的標準資源操做接口(CRUD)
這是RESTful Web API 和RPC風格面向功能操做集合的SOAP Web Service的Web API區分的一個主要特徵。URI中不包含動詞，動詞使用HTTP謂詞（Method）。返回結果影響到接口的統一性，要求全部的返回碼必須經過HTTP狀態碼來返回，另外，客戶端從服務端取得的不是資源自己，而是資源的表現形式。
標準接口即爲不一樣（資源）Web API定義一致性的操做來管理各自的資源，從資源角度去組織接口，並且不一樣資源操做都一致，不像RPC風格的Web API 只是從功能操做角度去考慮和組織操做。
一致的操做即CRUD，以下
public class ResourceService
{
public IEnumerable<Resource> Get();
public void Create(Resource resource);
public void Update(Resource resource);
public void Delete(string id);
}
另外，一個Web API 來管理角色的增刪查，以及創建和刪除角色和用戶之間的映射關係。RPC、SOAP風格的Web API 定義以下：
public class RoleService
{
public IEnumerable<string> GetAllRoles();
public void CreateRole(string roleName);
public void DeleteRole(string roleName);
public void AddRolesInUser(string userName, string[] roleNames);
public void RemoveRolesFromUsers(string userName, string[] roleNames);
}
其實，其中包含兩種資源，角色和角色委派，改爲統一接口
public class RoleService
{
public IEnumerable<string> GetAllRoles();
public void CreateRole(string roleName);
public void DeleteRole(string roleName);
}
public class RoleAssignmentService
{
public void Create( RoleAssignment roleName);
public void Delete( RoleAssignment roleName);
}
統一接口方法名，類名隱含了資源類別，不一樣資源操做，組織到不一樣類中，採用統一的接口，而不是像RPC風格接口，統一放一個類裏，經過不一樣方法名區分。
四、使用標準的HTTP方法
經常使用就是前邊列出的其中Http方法，好比新增資源
POST http://www.myhost/employees HTTP/1.1,請求主體中附上資源內容
另外，HTTP方法具備兩個基本特性，安全性和冪等性。
GET、HEAD、OPTIONS是安全方法，只是獲取數據，沒有邊界效應或反作用，另外四個方法，POST、PUT、PATCH、DELETE會致使服務器資源變化，因此是不安全的。
冪等性，即發送一次和屢次請求引發的邊界效應或反作用是同樣的。設計API時候，儘可能根據請求HTTP方法的冪等性來決定處理邏輯。
GET、HEAD、OPTIONS是冪等方法，DELETE和PATCH也是冪等的，都是對現有的某個資源操做，屢次操做效果都同樣，POST屢次操做會增長多個資源，因此不是冪等的，PUT通常狀況下也是冪等的，由於第一次不存在時候會添加，第二次操做存在了只會修改，對於PUT在特殊狀況下是非冪等的，對於每次修改操做都修改一個版本號，可是有時候這種非冪等性不是很是重要。
五、多種資源表示方式（內容協商機制）
資源根據媒體類型有不一樣的表現形式，每次請求能夠設定須要哪一種資源的表示形式，如是須要XML仍是JSON格式的資源。
一般是利用」內容協商機制」來實現，在請求報頭，Accept和Accept-language設置它所但願的資源表示，即媒體類型和語言。
還有種方式是在URL中包含資源表示。
六、無狀態性
RESTful只維護服務器上資源狀態，而不維護客戶端的狀態；Web API 不記錄客戶端的之前的請求狀態，其由客戶端本身來維護。如分頁號，Web API 不會知道上次的請求分頁號，它只會根據傳入的當前分頁號來處理，上次分頁號有客戶端本身處理。是無狀態的，減除了客戶端親和度，集羣環境中有效實施負載均衡，每一臺部署了WEB API接口的服務器對每一個客戶端都是等效的。
3、如何設計友好的REST API
一、URI
URI通常由名稱和id組成
（1）、單層資源：
/users 全部的用戶列表
/users/1 id爲1的用戶
注意：名稱爲複數users , id最好爲uuid,使用簡單、無鎖，分佈式系統中獨立處理，各自插入數據，不用擔憂id衝突。
（2）、多層資源
/users/1/files 用戶1的全部文件
/users/1/files/2 用戶1的文件中id爲2的文件
層數和參數不要太多，使用起來不方便，2層足夠
（3）、查詢參數不要放在URI中
/users/age/20/60 很差
/users?minAge=20&maxAge=60 寫成url參數
二、資源拆分
資源與領域類具備至關高的對應關係。
三、資源命名
（1）、資源名稱應該是名詞或動名詞形式，不要使用動詞
好比建立和註銷安全令牌 設計成 POST /tokens DELETE /tokens/{id}
（2）、注意名稱的表意性，恰如其分的表示業務含義，不要太囉嗦
files而不要寫成userFiles 太囉嗦
（3）、不要使用縮寫詞，避免使用有歧義或自創的所寫詞。
四、方法
（1）、安全性
安全性指的是一項操做不會改變資源的狀態，該操做應該把資源當作只讀。GET、HEAD是安全的，POST、PUT、DELETE、PATCH是不安全的。
可是，不是說不改變資源的狀態，就不能改變服務器任何東西，好比GET方法中能夠記錄日誌，不違反規範。
通常對安全的請求進行緩存，因此能夠充分利用互聯網的各級緩存設施。
若是你的GET方法會改變資源狀態，很容易遭受到攻擊，好比，GET請求進行投票，這樣把GET方法的地址發到論壇或QQ羣裏，有人點擊，就能夠投票了。
（2）、冪等性
意義在於安全的自動重試剛纔的操做，而不用擔憂破壞業務邏輯。
例如，瀏覽器中普通頁面能夠隨意刷新，表單提交的頁面刷新會彈出一個警告，問你是否確實要重試，這是由於POST操做是不冪等的，自動重試會致使預期以外的結果。
GET是冪等的，不管執行多少次都沒區別，
POST不是冪等的，再執行一次會建立一個新的資源
DELETE 冪等的 ，用相同的數據去更新資源，不管執行多少次，其效果都同樣
五、返回值
REST風格中，成功、失敗等錯誤碼應該在響應頭中做爲HTTP Status code 返回，不能在響應體中返回，這是HTTP規範也是REST規範要求。
咱們能夠在前端寫一個過濾層，對服務端的錯誤信息進行統一處理，AOP攔截。