REST是什么
REST（REpresentational State Transfer）是一個設計分布式web應用的框架風格，有六個基本原則：
Client-Server：應用的參獨立與者可分為Client和Server，Client和Server可以獨立發展和擴展。
Stateless：Client和Server之間的交互應該是stateless，server不應該記錄client的狀態，clent必須在請求中包含server可以理解的全部的必須的信息。
Layered System：Client和Server之間可存在多個分層，例如網關、防火牆、代理等，為了提高擴展性可以透明的增加、更改、刪除以及重新安排各個層之間的順序。
Cache：Server的響應應該聲明是否可以緩存，Client可以緩存能夠緩存的響應，以備將來的請求用，這可以減少Server的負載，並提高其性能。
Uniform Interface：統一接口是Client-Server、內部模塊之間交互的基礎，系統模塊只要遵循接口定義就可以獨自更新，而不影響其他模塊。統一接口可以分為四個約束：資源標識、資源表現、自描述信息、HATEOAS。
Code on demand：Client可以通過下載代碼擴展其功能，比如javasprit腳本、Silverlight等，這是一個可選約束。
應用程序如果能夠遵守上面六個約束，那么它就是Restfulf，但是這六個約束並不是開發技術，而只是一種能夠使應用程序更加可擴展、可適配、可重用的指導和最佳實踐。理論上，RESTful應用程序可以使用任何協議作為傳輸協議，但是在實踐中一般使用HTTP作為傳輸協議。
Uniform Interface約束是REST應用的關鍵屬性，可通過資源、資源表示、URIs、HTTP method等抽象技術實現。
資源
資源是REST應用的基礎，可以是任何可被訪問和管理的事物，比如視頻、博客文章、用戶配置文件、圖片等。
標識資源
我們必須能夠唯一標識一個資源，才能與它進行交互。Web提供了URI來唯一標識資源，它的語法是：
scheme:scheme-specific-part
scheme可以時http、ftp或者mailto等協議，它決定了URI其余部分的語義。一個URI可以唯一標識一個資源，但是一個資源可以有多個URI進行標識。
URI模板
在實際開發過程中，我們更多時候使用URI的結構而非URI本身，比如：
http://blog.example.com/{year}/posts
year部分是一個路徑變量，此URI代表year路徑變量指定的posts，而year能夠輕松被server解析。
資源表現方式
資源在REST應用中是一個抽象的實體，應能夠序列化為一種表現形式，以便和客戶端進行交流，這種表現形式可以看做資源實體的一個快照。Client和Server通過資源實體的表現形式交互，而非真正的資源實體。
資源實體的表現形式可以為text-based HTML、XML、JSON formats、binary formats（比如PDFs、
JPEGs、MP4s）等格式。Client和Server之間選定資源表現形式的過程稱為內容協商，一般內容協商可通過兩種方式：擴展名和Accept Header。
HTTP方法
可通過HTTP提供的方法對資源進行創建、更新、刪除、查詢等操作。
安全性
安全性指不會使資源狀態發生改變。
冪等性
冪等性指一個操作進行多次，資源返回相同的狀態。
GET
GET方法用於資源查詢，返回HTTP head和body，head記錄了資源的一些元信息，比如是否可以緩存、Content Type等，body中記錄了資源某個時間的狀態的表現形式，它是安全和冪等的。
HEAD
當用戶只關心資源是否存在或者是否有新版本，不關心資源的實體內容時，可使用HEAD方法進行查詢，它只返回HTTP頭，相比GET方法更加輕量。同GET方法一樣，HEAD方法是安全和冪等的。
DELETE
DELETE方法用於刪除資源，由於刪除操作可能比較費時，Server收到DELETE請求后，會首先返回一個確認消息，刪除操作可能過段時間才執行，當然了Server可根據具體業務邏輯決定是真正刪除資源還是標記一個標簽。DELETE方法時非安全和冪等的。
PUT
PUT方法用於修改資源狀態，需要Client發送包含資源全部信息的請求到Server，它是非安全和冪等的。
POST
POST方法用於創建資源，一般POST方法表示在某種資源集合中創建一個資源，所以URI中資源一般用復數表示。Server會在響應頭中用Location表示新創建的資源的URI。它是非安全和非冪等的。
PATCH
PATCH方法也用於資源的修改，不同於PUT方法的是：它允許只修改資源的部分屬性。請求body中要修改的部分信息可以采用以下幾種方式：
{"replace": "title","value": "New Awesome title"}
{"change" : "name", "from" : "Post Title", "to" : "New Awesome Title"}
{"name" : "New Awesome Title"}
它是非安全和冪等的。
HTTP狀態值
HTTP狀態值是Server告訴Client操作的執行結果。一般100系列的狀態值表示Server已經接到請求但是還未執行完畢；200系列的狀態值表示請求已被成功執行；300系列狀態值表示請求已被執行，但是Client還需另外的操作完成請求；400系列狀態值表示請求有格式、語法等錯誤；500系列狀態值表示Server在執行請求過程發生錯誤。
100 (Continue)：Indicates that the server has received the first part of the request and the rest
of the request should be sent.
200 (OK)：Indicates that all went well with the request.
201 (Created)：Indicates that request was completed and a new resource got created.
202 (Accepted)：Indicates that request has been accepted but is still being processed.
204 (No Content)：Indicates that the server has completed the request and has no entity body to send to the client.
301 (Moved Permanently)：Indicates that the requested resource has been moved to a new location and a new URI needs to be used to access the resource.
400 (Bad Request)：Indicates that the request is malformed and the server is not able to
understand the request.
401 (Unauthorized)：Indicates that the client needs to authenticate before accessing the resource. If the request already contains client’s credentials, then a 401 indicates invalid credentials (e.g., bad password).
403 (Forbidden)：Indicates that the server understood the request but is refusing to fulfill it. This could be because the resource is being accessed from a blacklisted IP address or outside the approved time window.
404 (Not Found)：Indicates that the resource at the requested URI doesn’t exist.
406 (Not Acceptable)：Indicates that the server is capable of processing the request; however, the generated response may not be acceptable to the client. This happens when the client becomes too picky with its accept headers.
500 (Internal Server Error)：Indicates that there was an error on the server while processing the request and that the request can’t be completed.
503 (Service Unavailable)：Indicates that the request can’t be completed, as the server is overloaded or going through scheduled maintenance.
RMM模型
RMM（The Richardson’s Maturity Model）表示了REST服務的四種級別：
Level 0
HTTP協議作為傳輸協議，通過唯一一個URI執行遠程調用，使用GET或者POST方法，SOAP-RPC和XML-RPC都屬於此類。
Level 1
Level 1比Level 0更加符合REST的要求，每個資源會有多個URI，但是會通過HTTP的一個方法（比如POST）執行所有的請求。
Level 2
能夠正確使用HTTP的方法和返回值。
Level 3
Level 3符合HATEOAS的概念，即在響應中包含相關資源的鏈接，可知道Client下一步該如何操作。
構建REST API
構建REST API分為如下四步：
Identify Resources：確定應用程序中的資源實體。
Identify Endpoints：為每個資源設計一個URI。
Identify Actions：為每個資源確定HTTP方法。
Identify Responses：為每個請求確定合適的返回值。