參考借鑒：http://www.cnblogs.com/loveis715/p/4669091.html
一杭跪、定義
REST其實(shí)是一種組織Web服務(wù)的架構(gòu)，而并不是我們想象的那樣是實(shí)現(xiàn)Web服務(wù)的一種新的技術(shù)绰精，更沒有要求一定要使用HTTP。其目標(biāo)是為了創(chuàng)建具有良好擴(kuò)展性的分布式系統(tǒng)诸衔。與目前常見的web設(shè)計(jì)架構(gòu)區(qū)別點(diǎn)在于着绷，REST是以資源為中心，而常規(guī)web架構(gòu)是以執(zhí)行了什么任務(wù)為中心。
二感耙、五大約束
1褂乍、使用客戶/服務(wù)器模型〖磁穑客戶和服務(wù)器之間通過一個(gè)統(tǒng)一的接口來互相通訊逃片。
2、層次化的系統(tǒng)只酥。在一個(gè)REST系統(tǒng)中褥实，客戶端并不會固定地與一個(gè)服務(wù)器打交道。
3层皱、無狀態(tài)性锭。在一個(gè)REST系統(tǒng)中，服務(wù)端并不會保存有關(guān)客戶的任何狀態(tài)叫胖。也就是說草冈，客戶端自身負(fù)責(zé)用戶狀態(tài)的維持，并在每次發(fā)送請求時(shí)都需要提供足夠的信息瓮增。
4怎棱、可緩存。REST系統(tǒng)需要能夠恰當(dāng)?shù)鼐彺嬲埱蟊僚埽员M量減少服務(wù)端和客戶端之間的信息傳輸拳恋，以提高性能。
5砸捏、統(tǒng)一的接口谬运。一個(gè)REST系統(tǒng)需要使用一個(gè)統(tǒng)一的接口來完成子系統(tǒng)之間以及服務(wù)與用戶之間的交互。這使得REST系統(tǒng)中的各個(gè)子系統(tǒng)可以獨(dú)自完成演化垦藏。（是REST服務(wù)設(shè)計(jì)的核心所在）
三梆暖、統(tǒng)一接口四個(gè)子約束
1、每個(gè)資源都擁有一個(gè)資源標(biāo)識掂骏。每個(gè)資源的資源標(biāo)識可以用來唯一地標(biāo)明該資源轰驳。
2、消息的自描述性弟灼。在REST系統(tǒng)中所傳遞的消息需要能夠提供自身如何被處理的足夠信息级解。例如該消息所使用的MIME類型，是否可以被緩存等田绑。
3勤哗、資源的自描述性。一個(gè)REST系統(tǒng)所返回的資源需要能夠描述自身掩驱，并提供足夠的用于操作該資源的信息芒划，如如何對資源進(jìn)行添加豁延，刪除以及修改等操作。也就是說腊状，一個(gè)典型的REST服務(wù)不需要額外的文檔對如何操作資源進(jìn)行說明。
4苔可、HATEOAS缴挖。即客戶只可以通過服務(wù)端所返回各結(jié)果中所包含的信息來得到下一步操作所需要的信息(客戶端僅可以決定資源ID)，如到底是向哪個(gè)URL發(fā)送請求等焚辅。也就是說映屋，一個(gè)典型的REST服務(wù)不需要額外的文檔標(biāo)示通過哪些URL訪問特定類型的資源，而是通過服務(wù)端返回的響應(yīng)來標(biāo)示到底能在該資源上執(zhí)行什么樣的操作同蜻。一個(gè)REST服務(wù)的客戶端也不需要知道任何有關(guān)哪里有什么樣的資源這種信息棚点。
四、資源操作方式
1湾蔓、GET 等冪且安全瘫析，讀取資源
2、DELETE 等冪 默责，刪除資源
3贬循、POST 不等冪，創(chuàng)建資源桃序，ID由服務(wù)端創(chuàng)建
4杖虾、PUT 等冪，創(chuàng)建資源和更新整個(gè)資源媒熊，ID由客戶端創(chuàng)建奇适，一般通過GUID和UUID
5、PATCH 等冪芦鳍，更新部分資源
注：等冪性嚷往，是指每次操作結(jié)果都一樣
五、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
六怜校、開發(fā)注意
對于一個(gè)基于HTTP的REST服務(wù)而言间影，軟件開發(fā)人員需要遵守如下的守則以保持API的后向兼容性（即兼容舊版本）：
1、不能在請求中添加新的必須的參數(shù)茄茁。
2魂贬、不能更改操作資源的動詞。
3裙顽、不能更改響應(yīng)的HTTP status付燥。
七、性能優(yōu)化
接下來我們就來簡單地說說基于HTTP的REST服務(wù)中的性能問題愈犹。在基于HTTP的REST服務(wù)中键科，性能提升主要分為兩個(gè)方面：REST架構(gòu)本身在提高性能方面做出的努力闻丑，以及基于HTTP協(xié)議的優(yōu)化。
首先要討論的就是對登陸性能的優(yōu)化勋颖。在前面我們已經(jīng)介紹過嗦嗡，在一個(gè)基于HTTP的REST服務(wù)中，每次都將用戶的用戶名和密碼發(fā)送到服務(wù)端并由服務(wù)端驗(yàn)證這些信息是否合法是一個(gè)非常消耗資源的流程饭玲。因此我們常常需要在登陸服務(wù)中使用一個(gè)緩存侥祭，或者是使用第三方單點(diǎn)登陸（SSO）類庫。
除此之外茄厘，軟件開發(fā)人員還可以通過為同一個(gè)資源提供不同的表現(xiàn)形式來減少在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量矮冬，從而提高REST服務(wù)的性能。
而在集群內(nèi)部服務(wù)之間次哈，我們則可以不再使用JSON胎署，XML等這種用戶可以讀懂的負(fù)載格式，而是使用二進(jìn)制格式窑滞。這樣可以大大地減少內(nèi)部網(wǎng)絡(luò)所需要傳輸?shù)臄?shù)據(jù)量琼牧。這在內(nèi)部網(wǎng)絡(luò)交換數(shù)據(jù)頻繁并且所傳輸?shù)臄?shù)據(jù)量巨大時(shí)較為有效。
接下來就是REST系統(tǒng)的橫向擴(kuò)展葛假。在REST的無狀態(tài)約束的支持下障陶，我們可以很容易地向REST系統(tǒng)中添加一個(gè)新的服務(wù)器。
除了這些和REST架構(gòu)本身相關(guān)的性能提升之外聊训，我們還可以在如何更高效地使用HTTP協(xié)議上努力抱究。一個(gè)最常見的方法就是使用條件請求（Conditional Request）。簡單地說带斑，我們可以使用如下的HTTP頭來有條件地存取資源：
1鼓寺、ETag：一個(gè)對用戶不透明的用來標(biāo)示資源實(shí)例的哈希值
2、Data-Modified：資源被更改的時(shí)間
3勋磕、If-Modified-Since：根據(jù)資源的更改時(shí)間有條件地Get資源妈候。這將允許客戶端對4、未更改的資源使用本地緩存挂滓。
5苦银、If-None-Match：根據(jù)ETag的值有條件地Get資源。
6赶站、If-Unmodified-Since：根據(jù)資源的更改時(shí)間有條件地Put或Delete資源幔虏。
7、If-Match：根據(jù)ETag的值有條件地Put或Delete資源贝椿。
當(dāng)然想括，這里所提到的一系列性能優(yōu)化方案實(shí)際上僅僅是比較常見的，與基于HTTP的REST服務(wù)關(guān)聯(lián)較大的方案烙博。只是顧慮到過多地陳述和REST關(guān)聯(lián)不大的話題一方面顯得比較沒有效率瑟蜈，另一方面也是因?yàn)橥ㄟ^寫另一個(gè)系列博客可以將問題陳述得更加清楚烟逊，因此在這里我們將不再繼續(xù)討論性能相關(guān)的話題。
