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