轉(zhuǎn)自：http://www.runoob.com/w3cnote/restful-architecture.html
1. 什么是REST
REST全稱是Representational State Transfer汇跨，中文意思是表述（編者注：通常譯為表征）性狀態(tài)轉(zhuǎn)移秘案。 它首次出現(xiàn)在2000年Roy Fielding的博士論文中芜壁，Roy Fielding是HTTP規(guī)范的主要編寫者之一。 他在論文中提到："我這篇文章的寫作目的裂问，就是想在符合架構(gòu)原理的前提下，理解和評估以網(wǎng)絡(luò)為基礎(chǔ)的應(yīng)用軟件的架構(gòu)設(shè)計，得到一個功能強垦梆、性能好诊赊、適宜通信的架構(gòu)厚满。REST指的是一組架構(gòu)約束條件和原則。" 如果一個架構(gòu)符合REST的約束條件和原則碧磅，我們就稱它為RESTful架構(gòu)碘箍。
REST本身并沒有創(chuàng)造新的技術(shù)、組件或服務(wù)鲸郊，而隱藏在RESTful背后的理念就是使用Web的現(xiàn)有特征和能力丰榴， 更好地使用現(xiàn)有Web標(biāo)準(zhǔn)中的一些準(zhǔn)則和約束。雖然REST本身受Web技術(shù)的影響很深秆撮， 但是理論上REST架構(gòu)風(fēng)格并不是綁定在HTTP上四濒，只不過目前HTTP是唯一與REST相關(guān)的實例。 所以我們這里描述的REST也是通過HTTP實現(xiàn)的REST。
2. 理解RESTful
要理解RESTful架構(gòu)峻黍，需要理解Representational State Transfer這個詞組到底是什么意思复隆，它的每一個詞都有些什么涵義。
下面我們結(jié)合REST原則姆涩，圍繞資源展開討論挽拂，從資源的定義、獲取骨饿、表述亏栈、關(guān)聯(lián)、狀態(tài)變遷等角度宏赘，列舉一些關(guān)鍵概念并加以解釋绒北。
- 資源與URI
- 統(tǒng)一資源接口
- 資源的表述
- 資源的鏈接
- 狀態(tài)的轉(zhuǎn)移
2. 1 資源與URI
REST全稱是表述性狀態(tài)轉(zhuǎn)移，那究竟指的是什么的表述? 其實指的就是資源察署。任何事物闷游，只要有被引用到的必要，它就是一個資源贴汪。資源可以是實體(例如手機(jī)號碼)脐往，也可以只是一個抽象概念(例如價值) 。下面是一些資源的例子：
- 某用戶的手機(jī)號碼
- 某用戶的個人信息
- 最多用戶訂購的GPRS套餐
- 兩個產(chǎn)品之間的依賴關(guān)系
- 某用戶可以辦理的優(yōu)惠套餐
- 某手機(jī)號碼的潛在價值
要讓一個資源可以被識別，需要有個唯一標(biāo)識，在Web中這個唯一標(biāo)識就是URI(Uniform Resource Identifier)隔箍。
URI既可以看成是資源的地址，也可以看成是資源的名稱梅尤。如果某些信息沒有使用URI來表示，那它就不能算是一個資源岩调， 只能算是資源的一些信息而已巷燥。URI的設(shè)計應(yīng)該遵循可尋址性原則，具有自描述性号枕，需要在形式上給人以直覺上的關(guān)聯(lián)矾湃。這里以github網(wǎng)站為例，給出一些還算不錯的URI：
- https://github.com/git
- https://github.com/git/git
- https://github.com/git/git/blob/master/block-sha1/sha1.h
- https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
- https://github.com/git/git/pulls
- https://github.com/git/git/pulls?state=closed
- https://github.com/git/git/compare/master…next
下面讓我們來看看URI設(shè)計上的一些技巧:
- 使用_或-來讓URI可讀性更好
曾經(jīng)Web上的URI都是冰冷的數(shù)字或者無意義的字符串堕澄，但現(xiàn)在越來越多的網(wǎng)站使用_或-來分隔一些單詞邀跃，讓URI看上去更為人性化。 例如國內(nèi)比較出名的開源中國社區(qū)蛙紫，它上面的新聞地址就采用這種風(fēng)格拍屑， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。
- 使用/來表示資源的層級關(guān)系
例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一個多級的資源坑傅， 指的是git用戶的git項目的某次提交記錄僵驰，又例如/orders/2012/10可以用來表示2012年10月的訂單記錄。
- 使用?用來過濾資源
很多人只是把?簡單的當(dāng)做是參數(shù)的傳遞，很容易造成URI過于復(fù)雜蒜茴、難以理解星爪。可以把?用于對資源的過濾粉私， 例如/git/git/pulls用來表示git項目的所有推入請求顽腾，而/pulls?state=closed用來表示git項目中已經(jīng)關(guān)閉的推入請求， 這種URL通常對應(yīng)的是一些特定條件的查詢結(jié)果或算法運算結(jié)果诺核。
- ,或;可以用來表示同級資源的關(guān)系
有時候我們需要表示同級資源的關(guān)系時抄肖，可以使用,或;來進(jìn)行分割。例如哪天github可以比較某個文件在隨意兩次提交記錄之間的差異窖杀，或許可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作為URI漓摩。 不過，現(xiàn)在github是使用…來做這個事情的入客，例如/git/git/compare/master…next管毙。
2. 2 統(tǒng)一資源接口
RESTful架構(gòu)應(yīng)該遵循統(tǒng)一接口原則，統(tǒng)一接口包含了一組受限的預(yù)定義的操作桌硫，不論什么樣的資源夭咬，都是通過使用相同的接口進(jìn)行資源的訪問。接口應(yīng)該使用標(biāo)準(zhǔn)的HTTP方法如GET鞍泉，PUT和POST，并遵循這些方法的語義肮帐。
如果按照HTTP方法的語義來暴露資源咖驮，那么接口將會擁有安全性和冪等性的特性，例如GET和HEAD請求都是安全的训枢， 無論請求多少次托修，都不會改變服務(wù)器狀態(tài)。而GET恒界、HEAD睦刃、PUT和DELETE請求都是冪等的，無論對資源操作多少次十酣， 結(jié)果總是一樣的涩拙，后面的請求并不會產(chǎn)生比第一次更多的影響。
下面列出了GET耸采，DELETE兴泥，PUT和POST的典型用法:
GET
安全且冪等
獲取表示
變更時獲取表示（緩存）
200（OK） - 表示已在響應(yīng)中發(fā)出
204（無內(nèi)容） - 資源有空表示
301（Moved Permanently） - 資源的URI已被更新
303（See Other） - 其他（如，負(fù)載均衡）
304（not modified）- 資源未更改（緩存）
400 （bad request）- 指代壞請求（如虾宇，參數(shù)錯誤）
404 （not found）- 資源不存在
406 （not acceptable）- 服務(wù)端不支持所需表示
500 （internal server error）- 通用錯誤響應(yīng)
503 （Service Unavailable）- 服務(wù)端當(dāng)前無法處理請求
POST
不安全且不冪等
使用服務(wù)端管理的（自動產(chǎn)生）的實例號創(chuàng)建資源
創(chuàng)建子資源
部分更新資源
如果沒有被修改搓彻，則不過更新資源（樂觀鎖）
200（OK）- 如果現(xiàn)有資源已被更改
201（created）- 如果新資源被創(chuàng)建
202（accepted）- 已接受處理請求但尚未完成（異步處理）
301（Moved Permanently）- 資源的URI被更新
303（See Other）- 其他（如，負(fù)載均衡）
400（bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務(wù)端不支持所需表示
409 （conflict）- 通用沖突
412 （Precondition Failed）- 前置條件失敗（如執(zhí)行條件更新時的沖突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用錯誤響應(yīng)
503 （Service Unavailable）- 服務(wù)當(dāng)前無法處理請求
PUT
不安全但冪等
用客戶端管理的實例號創(chuàng)建一個資源
通過替換的方式更新資源
如果未被修改旭贬，則更新資源（樂觀鎖）
200 （OK）- 如果已存在資源被更改
201 （created）- 如果新資源被創(chuàng)建
301（Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他（如怔接，負(fù)載均衡）
400 （bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務(wù)端不支持所需表示
409 （conflict）- 通用沖突
412 （Precondition Failed）- 前置條件失敗（如執(zhí)行條件更新時的沖突）
415 （unsupported media type）- 接受到的表示不受支持
500 （internal server error）- 通用錯誤響應(yīng)
503 （Service Unavailable）- 服務(wù)當(dāng)前無法處理請求
DELETE
不安全但冪等
刪除資源
200 （OK）- 資源已被刪除
301 （Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他稀轨，如負(fù)載均衡
400 （bad request）- 指代壞請求
404 （not found）- 資源不存在
409 （conflict）- 通用沖突
500 （internal server error）- 通用錯誤響應(yīng)
503 （Service Unavailable）- 服務(wù)端當(dāng)前無法處理請求
下面我們來看一些實踐中常見的問題:
- POST和PUT用于創(chuàng)建資源時有什么區(qū)別?
POST和PUT在創(chuàng)建資源的區(qū)別在于扼脐，所創(chuàng)建的資源的名稱(URI)是否由客戶端決定。 例如為我的博文增加一個java的分類靶端，生成的路徑就是分類名/categories/java谎势，那么就可以采用PUT方法。不過很多人直接把POST杨名、GET脏榆、PUT、DELETE直接對應(yīng)上CRUD台谍，例如在一個典型的rails實現(xiàn)的RESTful應(yīng)用中就是這么做的须喂。
我認(rèn)為，這是因為rails默認(rèn)使用服務(wù)端生成的ID作為URI的緣故趁蕊，而不少人就是通過rails實踐REST的坞生，所以很容易造成這種誤解。
- 客戶端不一定都支持這些HTTP方法吧?
的確有這種情況掷伙，特別是一些比較古老的基于瀏覽器的客戶端是己，只能支持GET和POST兩種方法。
在實踐上任柜，客戶端和服務(wù)端都可能需要做一些妥協(xié)卒废。例如rails框架就支持通過隱藏參數(shù)_method=DELETE來傳遞真實的請求方法， 而像Backbone這樣的客戶端MVC框架則允許傳遞_method傳輸和設(shè)置X-HTTP-Method-Override頭來規(guī)避這個問題宙地。
- 統(tǒng)一接口是否意味著不能擴(kuò)展帶特殊語義的方法?
統(tǒng)一接口并不阻止你擴(kuò)展方法摔认，只要方法對資源的操作有著具體的、可識別的語義即可宅粥，并能夠保持整個接口的統(tǒng)一性参袱。
像WebDAV就對HTTP方法進(jìn)行了擴(kuò)展，增加了LOCK秽梅、UPLOCK等方法抹蚀。而github的API則支持使用PATCH方法來進(jìn)行issue的更新，例如:
PATCH /repos/:owner/:repo/issues/:number
不過企垦，需要注意的是况鸣，像PATCH這種不是HTTP標(biāo)準(zhǔn)方法的，服務(wù)端需要考慮客戶端是否能夠支持的問題竹观。
- 統(tǒng)一資源接口對URI有什么指導(dǎo)意義?
統(tǒng)一資源接口要求使用標(biāo)準(zhǔn)的HTTP方法對資源進(jìn)行操作镐捧，所以URI只應(yīng)該來表示資源的名稱潜索，而不應(yīng)該包括資源的操作。
通俗來說懂酱，URI不應(yīng)該使用動作來描述竹习。例如，下面是一些不符合統(tǒng)一接口要求的URI:
- GET /getUser/1
- POST /createUser
- PUT /updateUser/1
- DELETE /deleteUser/1
如果GET請求增加計數(shù)器列牺，這是否違反安全性?
安全性不代表請求不產(chǎn)生副作用整陌，例如像很多API開發(fā)平臺，都對請求流量做限制瞎领。像github泌辫，就會限制沒有認(rèn)證的請求每小時只能請求60次。
但客戶端不是為了追求副作用而發(fā)出這些GET或HEAD請求的九默，產(chǎn)生副作用是服務(wù)端"自作主張"的震放。
另外，服務(wù)端在設(shè)計時驼修，也不應(yīng)該讓副作用太大殿遂，因為客戶端認(rèn)為這些請求是不會產(chǎn)生副作用的。
- 直接忽視緩存可取嗎?
即使你按各個動詞的原本意圖來使用它們乙各，你仍可以輕易禁止緩存機(jī)制墨礁。 最簡單的做法就是在你的HTTP響應(yīng)里增加這樣一個報頭： Cache-control: no-cache。 但是耳峦，同時你也對失去了高效的緩存與再驗證的支持(使用Etag等機(jī)制)恩静。
對于客戶端來說，在為一個REST式服務(wù)實現(xiàn)程序客戶端時蹲坷，也應(yīng)該充分利用現(xiàn)有的緩存機(jī)制驶乾，以免每次都重新獲取表示。
- 響應(yīng)代碼的處理有必要嗎?
HTTP的響應(yīng)代碼可用于應(yīng)付不同場合冠句，正確使用這些狀態(tài)代碼意味著客戶端與服務(wù)器可以在一個具備較豐富語義的層次上進(jìn)行溝通轻掩。
例如幸乒，201（"Created"）響應(yīng)代碼表明已經(jīng)創(chuàng)建了一個新的資源懦底，其URI在Location響應(yīng)報頭里。
假如你不利用HTTP狀態(tài)代碼豐富的應(yīng)用語義罕扎，那么你將錯失提高重用性聚唐、增強互操作性和提升松耦合性的機(jī)會。
如果這些所謂的RESTful應(yīng)用必須通過響應(yīng)實體才能給出錯誤信息腔召，那么SOAP就是這樣的了杆查，它就能夠滿足了。
2. 3 資源的表述
上面提到臀蛛，客戶端通過HTTP方法可以獲取資源亲桦，是吧? 不崖蜜，確切的說，客戶端獲取的只是資源的表述而已客峭。 資源在外界的具體呈現(xiàn)豫领，可以有多種表述(或成為表現(xiàn)、表示)形式舔琅，在客戶端和服務(wù)端之間傳送的也是資源的表述等恐，而不是資源本身。 例如文本資源可以采用html备蚓、xml课蔬、json等格式，圖片可以使用PNG或JPG展現(xiàn)出來郊尝。
資源的表述包括數(shù)據(jù)和描述數(shù)據(jù)的元數(shù)據(jù)二跋，例如，HTTP頭"Content-Type" 就是這樣一個元數(shù)據(jù)屬性虚循。
那么客戶端如何知道服務(wù)端提供哪種表述形式呢?
答案是可以通過HTTP內(nèi)容協(xié)商同欠，客戶端可以通過Accept頭請求一種特定格式的表述，服務(wù)端則通過Content-Type告訴客戶端資源的表述形式横缔。
以github為例铺遂，請求某組織資源的json格式的表述形式:
假如github也能夠支持xml格式的表述格式，那么結(jié)果就是這樣的:
下面我們來看一些實踐上常見的設(shè)計:
在URI里邊帶上版本號
有些API在URI里邊帶上版本號茎刚，例如:
如果我們把版本號理解成資源的不同表述形式的話襟锐，就應(yīng)該只是用一個URL，并通過Accept頭部來區(qū)分膛锭，還是以github為例粮坞，它的Accept的完整格式是:application/vnd.github[.version].param[+json]
對于v3版本的話，就是Accept: application/vnd.github.v3初狰。對于上面的例子莫杈，同理可以使用使用下面的頭部:
- Accept: vnd.example-com.foo+json; version=1.0
- Accept: vnd.example-com.foo+json; version=1.2
- Accept: vnd.example-com.foo+json; version=2.0
使用URI后綴來區(qū)分表述格式
像rails框架，就支持使用/users.xml或/users.json來區(qū)分不同的格式奢入。 這樣的方式對于客戶端來說筝闹，無疑是更為直觀，但混淆了資源的名稱和資源的表述形式腥光。 我個人認(rèn)為关顷，還是應(yīng)該優(yōu)先使用內(nèi)容協(xié)商來區(qū)分表述格式。
如何處理不支持的表述格式
當(dāng)服務(wù)器不支持所請求的表述格式武福，那么應(yīng)該怎么辦议双？若服務(wù)器不支持，它應(yīng)該返回一個HTTP 406響應(yīng)捉片，表示拒絕處理該請求平痰。下面以github為例汞舱，展示了一個請求XML表述資源的結(jié)果：
2. 4 資源的鏈接
我們知道REST是使用標(biāo)準(zhǔn)的HTTP方法來操作資源的，但僅僅因此就理解成帶CURD的Web數(shù)據(jù)庫架構(gòu)就太過于簡單了宗雇。
這種反模式忽略了一個核心概念："超媒體即應(yīng)用狀態(tài)引擎（hypermedia as the engine of application state）"兵拢。 超媒體是什么?
當(dāng)你瀏覽Web網(wǎng)頁時，從一個連接跳到一個頁面逾礁，再從另一個連接跳到另外一個頁面说铃，就是利用了超媒體的概念：把一個個把資源鏈接起來.
要達(dá)到這個目的，就要求在表述格式里邊加入鏈接來引導(dǎo)客戶端嘹履。在《RESTful Web Services》一書中腻扇，作者把這種具有鏈接的特性成為連通性。下面我們具體來看一些例子砾嫉。
下面展示的是github獲取某個組織下的項目列表的請求幼苛，可以看到在響應(yīng)頭里邊增加Link頭告訴客戶端怎么訪問下一頁和最后一頁的記錄。 而在響應(yīng)體里邊焕刮，用url來鏈接項目所有者和項目地址舶沿。
又例如下面這個例子，創(chuàng)建訂單后通過鏈接引導(dǎo)客戶端如何去付款配并。
上面的例子展示了如何使用超媒體來增強資源的連通性括荡。很多人在設(shè)計RESTful架構(gòu)時，使用很多時間來尋找漂亮的URI溉旋，而忽略了超媒體畸冲。所以，應(yīng)該多花一些時間來給資源的表述提供鏈接观腊，而不是專注于"資源的CRUD"邑闲。
2. 5 狀態(tài)的轉(zhuǎn)移
有了上面的鋪墊，再討論REST里邊的狀態(tài)轉(zhuǎn)移就會很容易理解了梧油。
不過苫耸，我們先來討論一下REST原則中的無狀態(tài)通信原則儡陨。初看一下，好像自相矛盾了迄委，既然無狀態(tài)类少，何來狀態(tài)轉(zhuǎn)移一說?
其實，這里說的無狀態(tài)通信原則硫狞，并不是說客戶端應(yīng)用不能有狀態(tài)信轿，而是指服務(wù)端不應(yīng)該保存客戶端狀態(tài)晃痴。
2. 5.1 應(yīng)用狀態(tài)與資源狀態(tài)
實際上，狀態(tài)應(yīng)該區(qū)分應(yīng)用狀態(tài)和資源狀態(tài)财忽，客戶端負(fù)責(zé)維護(hù)應(yīng)用狀態(tài)倘核，而服務(wù)端維護(hù)資源狀態(tài)。
客戶端與服務(wù)端的交互必須是無狀態(tài)的即彪，并在每一次請求中包含處理該請求所需的一切信息紧唱。
服務(wù)端不需要在請求間保留應(yīng)用狀態(tài)，只有在接受到實際請求的時候隶校，服務(wù)端才會關(guān)注應(yīng)用狀態(tài)漏益。
這種無狀態(tài)通信原則，使得服務(wù)端和中介能夠理解獨立的請求和響應(yīng)深胳。
在多次請求中绰疤，同一客戶端也不再需要依賴于同一服務(wù)器，方便實現(xiàn)高可擴(kuò)展和高可用性的服務(wù)端舞终。
但有時候我們會做出違反無狀態(tài)通信原則的設(shè)計轻庆，例如利用Cookie跟蹤某個服務(wù)端會話狀態(tài)，常見的像J2EE里邊的JSESSIONID敛劝。
這意味著余爆，瀏覽器隨各次請求發(fā)出去的Cookie是被用于構(gòu)建會話狀態(tài)的。
當(dāng)然夸盟，如果Cookie保存的是一些服務(wù)器不依賴于會話狀態(tài)即可驗證的信息（比如認(rèn)證令牌）龙屉，這樣的Cookie也是符合REST原則的。
2. 5.2 應(yīng)用狀態(tài)的轉(zhuǎn)移
狀態(tài)轉(zhuǎn)移到這里已經(jīng)很好理解了满俗， "會話"狀態(tài)不是作為資源狀態(tài)保存在服務(wù)端的转捕，而是被客戶端作為應(yīng)用狀態(tài)進(jìn)行跟蹤的∷衾客戶端應(yīng)用狀態(tài)在服務(wù)端提供的超媒體的指引下發(fā)生變遷五芝。服務(wù)端通過超媒體告訴客戶端當(dāng)前狀態(tài)有哪些后續(xù)狀態(tài)可以進(jìn)入。
這些類似"下一頁"之類的鏈接起的就是這種推進(jìn)狀態(tài)的作用——指引你如何從當(dāng)前狀態(tài)進(jìn)入下一個可能的狀態(tài)辕万。
3. 總結(jié)
現(xiàn)在廣東XXX版本枢步、XXX等項目中均使用傳統(tǒng)的RPC、SOAP方式的Web服務(wù)渐尿，而移動南方基地XXXX項目的后臺醉途， 雖然采用了JSON格式進(jìn)行交互，但還是屬于RPC風(fēng)格的砖茸。本文從資源的定義、獲取货葬、表述、關(guān)聯(lián)震桶、狀態(tài)變遷等角度蹲姐， 試圖快速理解RESTful架構(gòu)背后的概念。RESTful架構(gòu)與傳統(tǒng)的RPC寝衫、SOAP等方式在理念上有很大的不同拐邪，希望本文能對各位理解REST有所幫助扎阶。
