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是一種架構風格，這種風格基於一套預定義的規則，這些規則描述了網絡資源是如何定義和尋址的。
1、資源：萬物看成資源
2、統一接口：CRUD，跟Http Method對應。Create---Post、Read----Get、Update---Put/Patch、Delete----Delete。
3、URI：統一資源定位符，資源對應的唯一地址
4、無狀態：基於HTTP協議的，前后是不關聯的。（登錄系統---查詢工資---計算稅收，這 是有狀態的）。無狀態的意思就是，直接一個地址，就能拿到工資，就能得到稅收。
RESTFul的6個約束，每一個約束對API都有正面或負面的影響
REST所關注的性能，可擴展、間接性、互操作性、通訊可見性、組件便攜性和可靠性都包含在這6個約束里。
1、客戶端-服務端約束：客戶端和服務端是分離的，它們可以獨自的進化
2、無狀態：客戶端和服務端的通訊必須是無狀態的，狀態應該包含在請求里的，也就是說請求里要包含服務端需要的所有的信息，以便服務端可以理解請求並可以創造上下文
3、分層系統：就像其他的軟件架構一樣REST也需要分層結構的，但是不允許某層直接訪問不相鄰的層
4、統一接口：這里分為4點，他們是，資源標識符（URI）、資源的操作（也就是方法Method，HTTP動詞）、自描述的響應（可以認為是媒體類型Media-Type）、以及狀態管理（超媒體作為應用狀態的引擎HATEOAS，Hypermedia as the Engine of Application State）
5、緩存：緩存約束派生於無狀態約束，它要求從服務端返回的響應必須明確表明是可緩存的還是不可緩存的
6、按需編碼：這允許客戶端可以從服務端訪問特定的資源而無需知曉如何處理它們，服務端可以擴展或自定義客戶端的功能。
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.