今天抽空整理些有關(guān)rest方面的理論。主要參考了幾篇網(wǎng)上的文章，做了些整理，原文見附錄。
一、起源
越來越多的人開始意識到，網(wǎng)站即軟件，而且是一種新型的軟件。
這種"互聯(lián)網(wǎng)軟件"采用客戶端/服務(wù)器模式，建立在分布式體系上，通過互聯(lián)網(wǎng)通信，具有高延時（high latency）、高并發(fā)等特點。
網(wǎng)站開發(fā)，完全可以采用軟件開發(fā)的模式。但是傳統(tǒng)上，軟件和網(wǎng)絡(luò)是兩個不同的領(lǐng)域，很少有交集；軟件開發(fā)主要針對單機環(huán)境，網(wǎng)絡(luò)則主要研究系統(tǒng)之間的通信?；ヂ?lián)網(wǎng)的興起，使得這兩個領(lǐng)域開始融合，現(xiàn)在我們必須考慮，如何開發(fā)在互聯(lián)網(wǎng)環(huán)境中使用的軟件。
RESTful架構(gòu)，就是一種互聯(lián)網(wǎng)軟件架構(gòu)。它結(jié)構(gòu)清晰、符合標(biāo)準(zhǔn)、易于理解、擴展方便，所以正得到越來越多網(wǎng)站的采用。
二、名稱
Fielding將他對互聯(lián)網(wǎng)軟件的架構(gòu)原則，定名為REST，即Representational State Transfer的縮寫。我對這個詞組的翻譯是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
如果一個架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)。
要理解RESTful架構(gòu)，最好的方法就是去理解Representational State Transfer這個詞組到底是什么意思，它的每一個詞代表了什么涵義。如果你把這個名稱搞懂了，也就不難體會REST是一種什么樣的設(shè)計。
三、資源（Resources）
REST的名稱"表現(xiàn)層狀態(tài)轉(zhuǎn)化"中，省略了主語。"表現(xiàn)層"其實指的是"資源"（Resources）的"表現(xiàn)層"。
所謂"資源"，就是網(wǎng)絡(luò)上的一個實體，或者說是網(wǎng)絡(luò)上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務(wù)，總之就是一個具體的實在。你可以用一個URI（統(tǒng)一資源定位符）指向它，每種資源對應(yīng)一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
所謂"上網(wǎng)"，就是與互聯(lián)網(wǎng)上一系列的"資源"互動，調(diào)用它的URI。
四、表現(xiàn)層（Representation）
"資源"是一種信息實體，它可以有多種外在表現(xiàn)形式。我們把"資源"具體呈現(xiàn)出來的形式，叫做它的"表現(xiàn)層"（Representation）。
比如，文本可以用txt格式表現(xiàn)，也可以用HTML格式、XML格式、JSON格式表現(xiàn)，甚至可以采用二進制格式；圖片可以用JPG格式表現(xiàn)，也可以用PNG格式表現(xiàn)。
URI只代表資源的實體，不代表它的形式。嚴(yán)格地說，有些網(wǎng)址最后的".html"后綴名是不必要的，因為這個后綴名表示格式，屬于"表現(xiàn)層"范疇，而URI應(yīng)該只代表"資源"的位置。它的具體表現(xiàn)形式，應(yīng)該在HTTP請求的頭信息中用Accept和Content-Type字段指定，這兩個字段才是對"表現(xiàn)層"的描述。
五、狀態(tài)轉(zhuǎn)化（State Transfer）
訪問一個網(wǎng)站，就代表了客戶端和服務(wù)器的一個互動過程。在這個過程中，勢必涉及到數(shù)據(jù)和狀態(tài)的變化。
互聯(lián)網(wǎng)通信協(xié)議HTTP協(xié)議，是一個無狀態(tài)協(xié)議。這意味著，所有的狀態(tài)都保存在服務(wù)器端。因此，如果客戶端想要操作服務(wù)器，必須通過某種手段，讓服務(wù)器端發(fā)生"狀態(tài)轉(zhuǎn)化"（State Transfer）。而這種轉(zhuǎn)化是建立在表現(xiàn)層之上的，所以就是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
客戶端用到的手段，只能是HTTP協(xié)議。具體來說，就是HTTP協(xié)議里面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應(yīng)四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用于更新資源），PUT用來更新資源，DELETE用來刪除資源。
六、綜述
綜合上面的解釋，我們總結(jié)一下什么是RESTful架構(gòu)：
?。?）每一個URI代表一種資源；
?。?）客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；
（3）客戶端通過四個HTTP動詞，對服務(wù)器端資源進行操作，實現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。
REST關(guān)鍵原則
一個簡單扼要的定義：REST定義了應(yīng)該如何正確地使用Web標(biāo)準(zhǔn)，例如HTTP和URI。如果你在設(shè)計應(yīng)用程序時能堅持REST原則，那就預(yù)示著你將會得到一個使用了優(yōu)質(zhì)Web架構(gòu)（這將讓你受益）的系統(tǒng)?？傊?，五條關(guān)鍵原則列舉如下：
- 為所有“事物”定義ID
- 將所有事物鏈接在一起
- 使用標(biāo)準(zhǔn)方法
- 資源多重表述
- 無狀態(tài)通信
為所有“事物”定義ID
在這里我使用了“事物”來代替更正式準(zhǔn)確的術(shù)語“資源”，因為一條如此簡單的原則，不應(yīng)該被淹沒在術(shù)語當(dāng)中。思考一下人們構(gòu)建的系統(tǒng)，通常會找到一系列值得被標(biāo)識的關(guān)鍵抽象。每個事物都應(yīng)該是可標(biāo)識的，都應(yīng)該擁有一個明顯的ID——在Web中，代表ID的統(tǒng)一概念是：URI。URI構(gòu)成了一個全局命名空間，使用URI標(biāo)識你的關(guān)鍵資源意味著它們獲得了一個唯一、全局的ID。
值得被URI標(biāo)識的事物——資源——要比數(shù)據(jù)庫記錄抽象的多。標(biāo)識所有值得標(biāo)識的事物，領(lǐng)會這個觀念可以進一步引導(dǎo)你創(chuàng)造出在傳統(tǒng)的應(yīng)用程序設(shè)計中不常見的資源：一個流程或者流程步驟、一次銷售、一次談判、一份報價請求——這都是應(yīng)該被標(biāo)識的事物的示例。
將所有事物鏈接在一起
接下來要討論的原則有一個有點令人害怕的正式描述：“超媒體被當(dāng)作應(yīng)用狀態(tài)引擎（Hypermedia as the engine of application state）”，有時簡寫為HATEOAS。（嚴(yán)格地說，這不是我說的。）這個描述的核心是超媒體概念，換句話說：是鏈接的思想。鏈接是我們在HTML中常見的概念，但是它的用處絕不局限于此（用于人們網(wǎng)絡(luò)瀏覽）。
使用標(biāo)準(zhǔn)方法
在前兩個原則的討論中暗含著一個假設(shè)：接收URI的應(yīng)用程序可以通過URI明確地做一些有意義的事情。如果你在公共汽車上看到一個URI，你可以將它輸入瀏覽器的地址欄中并回車——但是你的瀏覽器如何知道需要對這個URI做些什么呢？
它知道如何去處理URI的原因在于所有的資源都支持同樣的接口，一套同樣的方法（只要你樂意，也可以稱為操作）集合。在HTTP中這被叫做動詞（verb），除了兩個大家熟知的（GET和POST）之外，標(biāo)準(zhǔn)方法集合中還包含PUT、DELETE、HEAD和OPTIONS。這些方法的含義連同行為許諾都一起定義在HTTP規(guī)范之中。
資源多重表述
在實踐中，資源多重表述還有著其它重要的好處：如果你為你的資源提供HTML和XML兩種表述方式，那這些資源不僅可以被你的應(yīng)用所用，還可以被任意標(biāo)準(zhǔn)Web瀏覽器所用——也就是說，你的應(yīng)用信息可以被所有會使用Web的人獲取到。
無狀態(tài)通信
首先，需要著重強調(diào)的是，雖然REST包含無狀態(tài)性（statelessness）的觀念，但這并不是說暴露功能的應(yīng)用不能有狀態(tài)——
事實上，在大部分情況下這會導(dǎo)致整個做法沒有任何用處。REST要求狀態(tài)要么被放入資源狀態(tài)中，要么保存在客戶端上。
或者換句話說，服務(wù)器端不能保持除了單次請求之外的，任何與其通信的客戶端的通信狀態(tài)。這樣做的最直接的理由就是可伸縮性—— 如果服務(wù)器需要保持客戶端狀態(tài)，那么大量的客戶端交互會嚴(yán)重影響服務(wù)器的內(nèi)存可用空間（footprint）。（注意，要做到無狀態(tài)通信往往需要需要一些重新設(shè)計——不能簡單地將一些session狀態(tài)綁縛在URI上，然后就宣稱這個應(yīng)用是RESTful。）
但除此以外，其它方面可能顯得更為重要：無狀態(tài)約束使服務(wù)器的變化對客戶端是不可見的，因為在兩次連續(xù)的請求中，客戶端并不依賴于同一臺服務(wù)器。一個客戶端從某臺服務(wù)器上收到一份包含鏈接的文檔，當(dāng)它要做一些處理時，這臺服務(wù)器宕掉了，可能是硬盤壞掉而被拿去修理，可能是軟件需要升級重啟——如果這個客戶端訪問了從這臺服務(wù)器接收的鏈接，它不會察覺到后臺的服務(wù)器已經(jīng)改變了。
REST風(fēng)格的一個“化身”便是HTTP（以及一套相關(guān)的一套標(biāo)準(zhǔn)，比如URI）。
附錄:
1.深入淺出REST
http://www.infoq.com/cn/articles/rest-introduction2.理解Restful 架構(gòu)
http://www.ruanyifeng.com/blog/2011/09/restful.html3.Rest和soap比較
http://www.infoq.com/cn/articles/rest-soap-when-to-use-each4.Rest和Rpc比較
http://xinklabi.iteye.com/blog/807220