越來越多的人開始意識到，網站即軟體，而且是一種新型的軟體。

這種"網際網路軟體"採用客戶端/伺服器模式，建立在分散式體系上，通過網際網路通訊，具有高延時（high latency）、高併發等特點。

網站開發，完全可以採用軟體開發的模式。但是傳統上，軟體和網路是兩個不同的領域，很少有交集；軟體開發主要針對單機環境，網路則主要研究系統之間的通訊。網際網路的興起，使得這兩個領域開始融合，現在我們必須考慮，如何開發在網際網路環境中使用的軟體。

RESTful架構，就是目前最流行的一種網際網路軟體架構。它結構清晰、符合標準、易於理解、擴充套件方便，所以正得到越來越多網站的採用。

但是，到底什麼是RESTful架構，並不是一個容易說清楚的問題。

REST究竟是什麼？因為REST的內涵非常豐富，所以很難用一兩句話解釋清楚這個問題。

下面，我就談談我理解的RESTful架構。

一、起源

    REST這個詞，是Roy Thomas Fielding在他2000年的博士論文中提出的。

Fielding將他對網際網路軟體的架構原則，定名為REST，即Representational State Transfer的縮寫。我對這個片語的翻譯是"表現層狀態轉化"。

如果一個架構符合REST原則，就稱它為RESTful架構。

Fielding是一個非常重要的人，他是HTTP協議（1.0版和1.1版）的主要設計者、Apache伺服器軟體的作者之一、Apache基金會的第一任主席。所以，他的這篇論文一經發表，就引起了關注，並且立即對網際網路開發產生了深遠的影響。

他這樣介紹論文的寫作目的：

"本文研究電腦科學兩大前沿----軟體和網路----的交叉點。長期以來，軟體研究主要關注軟體設計的分類、設計方法的演化，很少客觀地評估不同的設計選擇對系統行為的影響。而相反地，網路研究主要關注系統之間通訊行為的細節、如何改進特定通訊機制的表現，常常忽視了一個事實，那就是改變應用程式的互動風格比改變互動協議，對整體表現有更大的影響。我這篇文章的寫作目的，就是想在符合架構原理的前提下，理解和評估以網路為基礎的應用軟體的架構設計，得到一個功能強、效能好、適宜通訊的架構。"

二、名稱

要理解RESTful架構，最好的方法就是去理解Representational State Transfer這個片語到底是什麼意思，它的每一個詞代表了什麼涵義。

三、資源（Resources）

REST的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（Resources）的"表現層"。

所謂"資源"，就是網路上的一個實體，或者說是網路上的一個具體資訊。它可以是一段文字、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。

所謂"上網"，就是與網際網路上一系列的"資源"互動，呼叫它的URI。

四、表現層（Representation）

"資源"是一種資訊實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層"（Representation）。

比如，文字可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以採用二進位制格式；圖片可以用JPG格式表現，也可以用PNG格式表現。

URI只代表資源的實體，不代表它的形式。嚴格地說，有些網址最後的".html"字尾名是不必要的，因為這個字尾名錶示格式，屬於"表現層"範疇，而URI應該只代表"資源"的位置。它的具體表現形式，應該在HTTP請求的頭資訊中用Accept和Content-Type欄位指定，這兩個欄位才是對"表現層"的描述。

五、狀態轉化（State Transfer）

訪問一個網站，就代表了客戶端和伺服器的一個互動過程。在這個過程中，勢必涉及到資料和狀態的變化。

網際網路通訊協議HTTP協議，是一個無狀態協議。這意味著，所有的狀態都儲存在伺服器端。因此，如果客戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生"狀態轉化"（State Transfer）。而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。

客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議裡面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。

六、綜述

綜合上面的解釋，我們總結一下什麼是RESTful架構：

　　（1）每一個URI代表一種資源；

　　（2）客戶端和伺服器之間，傳遞這種資源的某種表現層；

　　（3）客戶端通過四個HTTP動詞，對伺服器端資源進行操作，實現"表現層狀態轉化"。

七、 舉個例子：

Marcus是一個農民，他有4頭豬，12只雞和3頭奶牛。他現在模擬一個REST API，而我是客戶端。如果我想用REST來請求當前的農場狀態，我僅會問：“State？”Marcus會回答：“4頭豬、12只雞、3頭奶牛”。

    這是REST最簡單的一個例子。Marcus使用表徵來傳輸農場狀態。表徵的句子很簡單：“4頭豬、12只雞、3頭奶牛”。

    再往下看，看我如何讓Marcus用REST方式新增2頭奶牛？

    按照常理，可以會這樣說：Marcus，請在農場你再新增2頭奶牛。難道這就是REST方式嗎？難道就是通過這樣的表徵來傳輸狀態的嗎？不是的！這是一個遠端過程呼叫，過程是給農場新增2頭奶牛。

    Marcus很憤怒地響應到：“400，Bad Request”，你到底是什麼意思？

所以，讓我們重新來一次。我們怎樣做到REST方式呢？該怎樣重新表徵呢？它應該是4頭豬、12只雞、3頭奶牛。好，讓我們再次重新表徵……

 我：“Marcus，……4頭豬、12只雞、5頭奶牛！”

    Marcus：“好的”。

我：“Marcus，現在是什麼狀態？”

    Marcus：“4頭豬、12只雞、5頭奶牛”。

    我：“好！”

    看到了嗎？就這樣簡單。

而restful就是滿足以下約束

使用客戶/伺服器模型。

     客戶和伺服器之間通過一個統一的介面來互相通訊。

 層次化的系統。

    在一個REST系統中，客戶端並不會固定地與一個伺服器打交道。

 無狀態。

    在一個REST系統中，服務端並不會儲存有關客戶的任何狀態。也就是說，客戶端自身負責使用者狀態的維持，並在每次傳送請求時都需要提供足夠的資訊。

可快取。

    REST系統需要能夠恰當地快取請求，以儘量減少服務端和客戶端之間的資訊傳輸，以提高效能。

統一的介面。

    一個REST系統需要使用一個統一的介面來完成子系統之間以及服務與使用者之間的互動。這使得REST系統中的各個子系統可以獨自完成演化。

如果一個系統滿足了上面所列出的五條約束，那麼該系統就被稱為是RESTful的。

八、誤區

RESTful架構有一些典型的設計誤區。

最常見的一種設計錯誤，就是URI包含動詞。因為"資源"表示一種實體，所以應該是名詞，URI不應該有動詞，動詞應該放在HTTP協議中。

舉例來說，某個URI是/posts/show/1，其中show是動詞，這個URI就設計錯了，正確的寫法應該是/posts/1，然後用GET方法表示show。

如果某些動作是HTTP動詞表示不了的，你就應該把動作做成一種資源。比如網上匯款，從賬戶1向賬戶2匯款500元，錯誤的URI是：

　　POST /accounts/1/transfer/500/to/2

正確的寫法是把動詞transfer改成名詞transaction，資源不能是動詞，但是可以是一種服務：

　　POST /transaction HTTP/1.1
　　Host: 127.0.0.1
　　
　　from=1&to=2&amount=500.00

另一個設計誤區，就是在URI中加入版本號：

　　http://www.example.com/app/1.0/foo

　　http://www.example.com/app/1.1/foo

　　http://www.example.com/app/2.0/foo

因為不同的版本，可以理解成同一種資源的不同表現形式，所以應該採用同一個URI。版本號可以在HTTP請求頭資訊的Accept欄位中進行區分（參見Versioning REST Services）：

　　Accept: vnd.example-com.foo+json; version=1.0

　　Accept: vnd.example-com.foo+json; version=1.1

　　Accept: vnd.example-com.foo+json; version=2.0

（完）