RESTFul&HTTP GET簡介

RestApi：https://www.cnblogs.com/springyangwc/archive/2012/01/18/2325784.html

RESTFul API設計指南：http://www.ruanyifeng.com/blog/2014/05/restful_api.html這篇是阮一峯老師寫的

RESTFul

　　由Roy Fielding提出的，RESTFul是一種架構風格，這種風格基於一套預約義的規則，這些規則描述了網絡資源是如何定義和尋址的。

　　一、資源：萬物當作資源

　　二、統一接口：CRUD，跟Http Method對應。Create---Post、Read----Get、Update---Put/Patch、Delete----Delete。

　　三、URI：統一資源定位符，資源對應的惟一地址

　　四、無狀態：基於HTTP協議的，先後是不關聯的。（登陸系統---查詢工資---計算稅收，這 是有狀態的）。無狀態的意思就是，直接一個地址，就能拿到工資，就能獲得稅收。

RESTFul的6個約束，每個約束對API都有正面或負面的影響

　　REST所關注的性能，可擴展、間接性、互操做性、通信可見性、組件便攜性和可靠性都包含在這6個約束裏。

　　一、客戶端-服務端約束：客戶端和服務端是分離的，它們能夠獨自的進化

　　二、無狀態：客戶端和服務端的通信必須是無狀態的，狀態應該包含在請求裏的，也就是說請求裏要包含服務端須要的全部的信息，以便服務端能夠理解請求並能夠創造上下文

　　三、分層系統：就像其餘的軟件架構同樣REST也須要分層結構的，可是不容許某層直接訪問不相鄰的層

　　四、統一接口：這裏分爲4點，他們是，資源標識符（URI）、資源的操做（也就是方法Method，HTTP動詞）、自描述的響應（能夠認爲是媒體類型Media-Type）、以及狀態管理（超媒體做爲應用狀態的引擎HATEOAS，Hypermedia as the Engine of Application State）

　　五、緩存：緩存約束派生於無狀態約束，它要求從服務端返回的響應必須明確代表是可緩存的仍是不可緩存的

　　六、按需編碼：這容許客戶端能夠從服務端訪問特定的資源而無需知曉如何處理它們，服務端能夠擴展或自定義客戶端的功能。

REST-Richardson成熟度模型表明API的成熟度，分4級，0最差，3最好。

　　0級，Plain Old XML沼澤：這裏HTTP協議只是被用來進行遠程交互，協議的其他部分都用錯了，都是RPC風格的實現（例如SOAP，尤爲是使用WCF的時候）

　　1級，資源：每一個資源都映射到一個URI上了，可是HTTP方法並無正確的使用，結果的複雜度不算過高

　　2級，動詞：正確使用了HTTP動詞，狀態碼也正確的使用了，同時也去掉了沒必要要的變種

　　3級，超媒體：API支持超媒體做爲應用狀態的引擎HATEOAS，Hypermedia as theEngine of Application State，引入了可發現性

HTTP GET Action

　　API資源命名資源應該是用動詞，它是個東西，不是動做

　　資源應該使用名詞，例如：

　　　　api/getusers  這個就是不正確的

　　　　GET api/users  就是正確的，或者GET api/users/{userId}

　　其中資源名的單詞我喜歡使用複數的形式

　　API資源命名--層次結構：

　　　　例如 api/department/{departmentId}/emoloyess，這幾表示了department（部門）和員工（employee）之間是主從關係。而api/department/{departmentId}/emplss/{emploId}，這就表示了該部門下的某個員工。

　　API資源命名--過濾排序

　　　　過濾和排序，不是資源，應該做爲參數，例如：

　　　　api/users？orderby=username

　　API資源的ID

　　　　資源的URI應該是永遠都同樣的，推薦GUID做爲ID來使用，自增int類型的ID，在遷移到新數據庫時須要特殊設定，保證ID值不會發生變化。

HTTP方法與資源交互

 

 注意：

　　HEAD：和GET差很少，可是它不該該返回響應的body，因此沒有響應的payload，它主要是用來獲取資源的一些信息，例如查看資源是否可用等

　　OPTIONS：它是用來查詢某個資源URI的可交互方式有哪些，換句話時候就是，使用它可用知道某個URI是否可用執行GET或者POST動做，這些動做一般是在響應的Header是裏面而不是body裏，因此也沒有響應的payload。

狀態碼

　　能夠參考：http://tool.oschina.net/commons?type=5

　　狀態碼會告訴API的消費者，請求是否如逾期的成功，或者失敗。若是出現了錯誤，誰該爲這個錯誤負責。

　　API主要用到了：

　　　　200級別，表示成功

 

　　　　400級別，表示客戶端引發的錯誤

　　　　500級別，表示服務器錯誤

內容協商：

　　若是資源支持多種展示格式，那麼消費者能夠選擇它想要的格式。在請求的Accept Header指定Media Type ，application/json，application/xml，若未指定，默認返回application/json，請求的media type不可用時，而且消費者不支持默認格式，返回406

APS.NET Core裏的內容協商：

　　ASP.NET Core支持輸出和輸入兩種格式化器。

　　　　用於輸出的media type放在Accept Header裏，表示客戶端接受這種格式的輸出。

　　　　用於輸入的media type放在Content-Type Header裏。表示客戶端傳進AI的數據是這種格式。

　　　　ReturnHttpNotAcceptable設爲true，就會返回406.