一、REST的基本思想
[Fielding]把REST形式化地定義為一種架構風格（architecture style），它由架構元素（element）和架構約束（constraint）組成。REST是一種針對網絡應用的設計和開發方式，可以降低開發的復雜性，提高系統的可伸縮性。REST提出了一些設計概念和准則：
1. 網絡上的所有事物都被抽象為資源（resource）；
2. 每個資源對應一個唯一的資源標識（resource identifier）；
3. 通過通用的連接器接口（generic connector interface）對資源進行操作；
4. 對資源的各種操作不會改變資源標識；
5. 所有的操作都是無狀態的（stateless）。
對於當今最常見的網絡應用來說，resource identifier是url，generic connector interface是HTTP，第4條准則就是我們常說的url不變性。這些概念中的resouce最容易使人產生誤解。resouce所指的並不是數據，而是數據+特定的表現形式（representation），這也是為什麼REST的全名是Representational State Transfer的原因。舉個例子來說，“本月賣得最好的10本書”和“你最喜歡的10本書”在數據上可能有重疊（有一本書即賣得好，你又喜歡），甚至完全相同。但是它們的representation不同，因此是不同的resource。
在web上，你能對資源采取的僅限於一些基本的操作。HTTP提供了四種基本方法，用於四種最常見的操作：
1. 獲取資源的一個表示：HTTP GET
2. 創建一個新資源：向一個新URI發送HTTP PUT，或者向一個已有URI發送HTTP POST.( PUT請求是由客戶端決定（被創建或更新的）資源的URI；而POST請求是向一個“集合（collection）”或 “工廠（factory）”資源發出的，是由服務器來指派URI的。)
3. 修改已有資源：向已有URI發送HTTP PUT
4. 刪除已有資源：HTTP DELETE
二、REST式、面向資源的架構
REST式的架構意味著方法信息method information都在HTTP方法（如GET，POST等，默認的HTTP方法是GET）裡，方法信息就是關於對數據采取什麼操作的信息，即Server端提供的業務方法，不能出現在URI裡；面向資源的架構Resource-Oriented Architecture意味著作用域信息scoping information都在URI裡，作用域信息可以理解為業務方法所需的一組參數。將二者結合起來是很強大的，即REST式、面向資源的架構。實際上很多HTTP請求的第一行就能讓Server端知道客戶端要做什麼了，請求的其余部分只是具體細節而已。如果HTTP方法跟方法信息對不上，那麼服務就算不上是REST式的；如果作用域信息不放在URI裡，那麼這項服務不是面向資源的。
三、RPC式架構
RPC式的web服務通常是Server端從客戶端收到一個充滿數據的信封envelope，信封裡或者報頭包含客戶端請求的方法信息與作用域信息，Server端處理請求後，同樣發給客戶端一個充滿信息的信封。RPC式的架構意味著方法信息與作用域信息都在信封或者報頭裡。具體采用哪種信封，沒有限制。HTTP是一種常見的信封格式，另一種常見的信封格式是SOAP，將SOAP信封放在HTTP信封裡，在HTTP上傳送SOAP文檔。XML-RPC是最典型的RPC架構的例子。下面是一段描述XML-RPC請求的XML文檔：
<?xml version=”1.0”>
<methodCall>
<methodName>lookupRPC</methodName>
<params>
<param><value><string>jfksajfksajfs</string></value></param>
</params>
</methodCall>
這個XML文檔是放在信封裡傳遞給服務器的，這裡的信封就是HTTP請求，它由HTTP方法，URI，包頭和實體主體等部分組成，其中實體主題就是上面的xml文檔。上面的XML文檔隨你調用方法的不同而有所變化，只是HTTP信封格式總是不變的，即URI與HTTP方法 POST是不變的，只是信封主體的XML文檔的methodName與params有變化。REST式的服務為不同的作用域信息暴露不同的URI；而RPC式的服務為每個“文檔處理器”（用於打開信封，並把信封轉化為軟件指令）暴露一個URI。
較多的采用或者只采用HTTP POST的服務多半是RPC式的服務。雖然這不是絕對的，但是至少可以說明該服務沒有把HTTP方法用於表達方法信息。如果一個REST式的服務過多地采用HTTP POST，那麼他容易變成REST-RPC混合架構。
四、REST-RPC混合架構
看這個URI：
http://www.myserver.com/services/rest?api_key=xxx&method=myserver.item.get&tags=book
雖然這個URI包含著rest字樣，但是它把方法信息myserver.item.get放在了URI裡了，這說明它不是采用rest式的架構了；但是作用域信息卻包含在URI裡了，這跟REST式、面向資源的架構有點類似了。該URI的HTTP請求為：
GET services/rest? api_key=xxx&method=myserver.item.get&tags=book HTTP/1.1
HOST:www.myserver.com
看上去好像確實是REST式的服務，方法信息和作用域信息都在頭部，沒有在實體主體中。這些RPC式的服務，不經意間或多或少的帶著點REST式的web服務的特征。他們只是把HTTP作為一種信封格式來用，不過他們使用HTTP信封的方式可能跟REST式的服務的做法雷同。
許多的只讀的web服務，盡管他們起初也許是按RPC風格來設計的，但可稱得上是完全的REST式和面向資源的，但是，如果該服務允許客戶端修改資源的話，就會出現客戶端所使用的HTTP方法與真正的方法信息不一致的情況，這樣就不具備REST式服務的特征，我們稱這類服務為REST-RPC混合服務。
總之，對於一個REST式的web服務，它會在HTTP方法裡（HTTP請求的第一行）尋找方法信息，在URI裡尋找方法的作用域信息；而RPC式的Web服務則往往忽略HTTP方法，在URI、HTTP報頭或者實體主體裡尋找方法信息與作用域信息。有些RPC式的web服務把HTTP作為一種容納文檔的信封，而另一些RPC式的web服務則把HTTP作為一種容納另一個信封的信封；一個REST式的面向資源的服務為客戶端可能操作的每一則數據暴露一個URI；一個REST-RPC混合服務為客戶端可能進行的每一個操作暴露一個URI（比如獲取數據用一個URI，修改數據用另一個URI）；一個RPC式服務為每個處理遠程調用的進程暴露一個URI。
