參考借鑒：http://www.cnblogs.com/loveis715/p/4669091.html
一、定義
REST其實是一種組織Web服務的架構，而并不是我們想象的那樣是實現Web服務的一種新的技術，更沒有要求一定要使用HTTP。其目標是為了創建具有良好擴展性的分布式系統。與目前常見的web設計架構區別點在于，REST是以資源為中心，而常規web架構是以執行了什么任務為中心。
二、五大約束
1、使用客戶/服務器模型。客戶和服務器之間通過一個統一的接口來互相通訊。
2、層次化的系統。在一個REST系統中，客戶端并不會固定地與一個服務器打交道。
3、無狀態。在一個REST系統中，服務端并不會保存有關客戶的任何狀態。也就是說，客戶端自身負責用戶狀態的維持，并在每次發送請求時都需要提供足夠的信息。
4、可緩存。REST系統需要能夠恰當地緩存請求，以盡量減少服務端和客戶端之間的信息傳輸，以提高性能。
5、統一的接口。一個REST系統需要使用一個統一的接口來完成子系統之間以及服務與用戶之間的交互。這使得REST系統中的各個子系統可以獨自完成演化。（是REST服務設計的核心所在）
三、統一接口四個子約束
1、每個資源都擁有一個資源標識。每個資源的資源標識可以用來唯一地標明該資源。
2、消息的自描述性。在REST系統中所傳遞的消息需要能夠提供自身如何被處理的足夠信息。例如該消息所使用的MIME類型，是否可以被緩存等。
3、資源的自描述性。一個REST系統所返回的資源需要能夠描述自身，并提供足夠的用于操作該資源的信息，如如何對資源進行添加，刪除以及修改等操作。也就是說，一個典型的REST服務不需要額外的文檔對如何操作資源進行說明。
4、HATEOAS。即客戶只可以通過服務端所返回各結果中所包含的信息來得到下一步操作所需要的信息(客戶端僅可以決定資源ID)，如到底是向哪個URL發送請求等。也就是說，一個典型的REST服務不需要額外的文檔標示通過哪些URL訪問特定類型的資源，而是通過服務端返回的響應來標示到底能在該資源上執行什么樣的操作。一個REST服務的客戶端也不需要知道任何有關哪里有什么樣的資源這種信息。
四、資源操作方式
1、GET 等冪且安全，讀取資源
2、DELETE 等冪 ，刪除資源
3、POST 不等冪，創建資源，ID由服務端創建
4、PUT 等冪，創建資源和更新整個資源，ID由客戶端創建，一般通過GUID和UUID
5、PATCH 等冪，更新部分資源
注：等冪性，是指每次操作結果都一樣
五、HTTP Code
參照：Hypermedia ControlsHypermedia Controlshttp://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
100 Continue
101 Switching
102 Processing
103-199 Unassigned
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
209-225 Unassigned
226 IM Used
227-299 Unassigned
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 (Unused)
307 Temporary Redirect
308 Permanent Redirect
309-399 Unassigned
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 URI Too Long
415 Unsupported Media Type
416 Range Not Satisfiable
417 Expectation Failed
418-420 Unassigned
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
425 Unassigned
426 Upgrade Required
427 Unassigned
428 Precondition Required
429 Too Many Requests
430 Unassigned
431 Request Header Fields Too Large
432-450 Unassigned
451 Unavailable For Legal Reasons
452-499 Unassigned
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
509 Unassigned
510 Not Extended
511 Network Authentication Required
512-599 Unassigned
六、開發注意
對于一個基于HTTP的REST服務而言，軟件開發人員需要遵守如下的守則以保持API的后向兼容性（即兼容舊版本）：
1、不能在請求中添加新的必須的參數。
2、不能更改操作資源的動詞。
3、不能更改響應的HTTP status。
七、性能優化
接下來我們就來簡單地說說基于HTTP的REST服務中的性能問題。在基于HTTP的REST服務中，性能提升主要分為兩個方面：REST架構本身在提高性能方面做出的努力，以及基于HTTP協議的優化。
首先要討論的就是對登陸性能的優化。在前面我們已經介紹過，在一個基于HTTP的REST服務中，每次都將用戶的用戶名和密碼發送到服務端并由服務端驗證這些信息是否合法是一個非常消耗資源的流程。因此我們常常需要在登陸服務中使用一個緩存，或者是使用第三方單點登陸（SSO）類庫。
除此之外，軟件開發人員還可以通過為同一個資源提供不同的表現形式來減少在網絡上傳輸的數據量，從而提高REST服務的性能。
而在集群內部服務之間，我們則可以不再使用JSON，XML等這種用戶可以讀懂的負載格式，而是使用二進制格式。這樣可以大大地減少內部網絡所需要傳輸的數據量。這在內部網絡交換數據頻繁并且所傳輸的數據量巨大時較為有效。
接下來就是REST系統的橫向擴展。在REST的無狀態約束的支持下，我們可以很容易地向REST系統中添加一個新的服務器。
除了這些和REST架構本身相關的性能提升之外，我們還可以在如何更高效地使用HTTP協議上努力。一個最常見的方法就是使用條件請求（Conditional Request）。簡單地說，我們可以使用如下的HTTP頭來有條件地存取資源：
1、ETag：一個對用戶不透明的用來標示資源實例的哈希值
2、Data-Modified：資源被更改的時間
3、If-Modified-Since：根據資源的更改時間有條件地Get資源。這將允許客戶端對4、未更改的資源使用本地緩存。
5、If-None-Match：根據ETag的值有條件地Get資源。
6、If-Unmodified-Since：根據資源的更改時間有條件地Put或Delete資源。
7、If-Match：根據ETag的值有條件地Put或Delete資源。
當然，這里所提到的一系列性能優化方案實際上僅僅是比較常見的，與基于HTTP的REST服務關聯較大的方案。只是顧慮到過多地陳述和REST關聯不大的話題一方面顯得比較沒有效率，另一方面也是因為通過寫另一個系列博客可以將問題陳述得更加清楚，因此在這里我們將不再繼續討論性能相關的話題。
