REST 是由 Roy Fielding 在他的論文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個術(shù)語。

REST 是英文 Representational State Transfer 的縮寫，有中文翻譯為“具象狀態(tài)傳輸”（參考：《SIP/IMS網(wǎng)絡(luò)中的Representational State Transfer (REST)和數(shù)據(jù)分布》）。

—————————————

前面的內(nèi)容比較枯燥，我說說我自己的理解。

但是 REST 到底是什么呢？論文我看不懂，不過找到一篇更簡單易懂的東西：《Building Web Services the REST Way》。

根據(jù)這篇文章，我整理了一下我自己對 REST 的理解：

REST 首先只是一種架構(gòu)樣式，不是一種標(biāo)準(zhǔn)。這點和 Ajax 類似，兩者都是利用現(xiàn)有的成熟技術(shù)。

在 REST 的定義中，一個 Web 應(yīng)用總是使用固定的 URI 向外部世界呈現(xiàn)（或者說暴露）一個資源。

URI 是英文 Uniform Resource Identifier 的縮寫，中文翻譯“通用資源標(biāo)志符”。

“通用資源標(biāo)志符”是指唯一標(biāo)識一個資源（xhtml 文件、圖片、css 樣式表）的字符串。當(dāng)然了，RFC 中定義的 URI 復(fù)雜得多，不過我們此處將 URI 想象成一個人的身份證號碼就行了（你不能有兩個同時有效的身份證號碼，一個號碼也不可能同時對應(yīng)兩個人）。而我們天天掛在嘴邊的 URL 地址就是 URI 的一種表現(xiàn)形式（個人理解，有錯請糾正）。

知道什么是 URI 后，我們來看一個實際例子：

http://www.example.com/photo/logo 指向 example.com 網(wǎng)站（可以視為一個 Web 應(yīng)用）中類型為 photo，名字為 logo 的資源。我們用瀏覽器訪問這個 URI，看到的將可能是一個 xhtml 文檔，其中用 <img src=”……” /> 來顯示實際的照片。

http://www.example.com/photo/logo 很容易讓你想到 URL 重寫。事實上，這個地址很可能會在服務(wù)器內(nèi)部處理為 http://www.example.com/photo.php?name=logo 這樣的地址。photo.php 是服務(wù)器端的一個動態(tài)腳本文件，根據(jù) name 參數(shù)生成 xhtml 文檔返回給瀏覽器。

現(xiàn)在假設(shè)我們要獲取這張照片的 XML 文檔。XML 文檔中包含照片的文件名、文件大小、拍攝日期等等信息。也就是說我們要獲取“同一個資源的不同表現(xiàn)形式的數(shù)據(jù)”。對于這個要求，我們可以很容易的用另一個 URL 地址達到：http://www.example.com/xml/logo。

但是，這就違背了“URI 唯一標(biāo)識一個資源”的定義。如果我們要獲取同一個資源的多種表現(xiàn)形式，那么就要使用更多的 URL，從而給一個資源指定了多個不同的 URI。

而在 REST 中，不管是獲取照片的 xhtml 文檔還是 XML 文檔，或者照片文件本身，都是用同一個 URI，就是 http://www.example.com/photo/logo。

那這是怎么辦到的呢？Ruby On Rails 中是通過分辨 HTTP Request Header 信息來分辨客戶端是想要取得資源的哪一種表現(xiàn)形式的數(shù)據(jù)。

當(dāng)我們用瀏覽器訪問一個網(wǎng)址時，瀏覽器會構(gòu)造一個 HTTP 請求。這個請求有一個頭信息，其中包括了本次請求接受何種類型的數(shù)據(jù)。通常瀏覽器發(fā)送的 HTTP 請求頭中，Accept 的值都是 */*，也就說接受服務(wù)器返回的任何類型的數(shù)據(jù)。

看到這里，聰明的家伙應(yīng)該知道了。只要我們指定一個特定的 Accept 參數(shù)，那么服務(wù)器就可以通過判斷該參數(shù)來決定返回什么類型的數(shù)據(jù)。所以在一個采用 REST 架構(gòu)的應(yīng)用中，要獲取同一個資源的不同表現(xiàn)形式的數(shù)據(jù)，只需要使用不同的 HTTP 請求頭信息就行了。

如果考慮為 Web 應(yīng)用增加 Web Services，這種技術(shù)的價值就體現(xiàn)出來了。比如我寫了一個 Delphi 程序，現(xiàn)在只需要構(gòu)造一個包含 Accept: text/xml 的 HTTP 請求頭，然后將請求發(fā)送到 http://www.example.com/photo/logo 就可以了。返回的結(jié)果就是一個 XML 文檔，而不是 xhtml 文檔。

因為我們的 HTTP 請求頭信息有不同的狀態(tài)，從而可以獲得不同的數(shù)據(jù)，所以叫做“具象狀態(tài)傳輸” :)

—————————————

除了上面的用法，REST 還有進一步的擴展。

我們在 Web 應(yīng)用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構(gòu)中，用不同的 HTTP 請求方法來處理對資源的 CRUD（創(chuàng)建、讀取、更新和刪除）操作：

  • POST: 創(chuàng)建
  • GET: 讀取
  • PUT: 更新
  • DELETE: 刪除

經(jīng)過這樣的一番擴展，我們對一個資源的 CRUD 操作就可以通過同一個 URI 完成了：

http://www.example.com/photo/logo（讀取）
仍然保持為 [GET] http://www.example.com/photo/logo

http://www.example.com/photo/logo/create（創(chuàng)建）
改為 [POST] http://www.example.com/photo/logo

http://www.example.com/photo/logo/update（更新）
改為 [PUT] http://www.example.com/photo/logo

http://www.example.com/photo/logo/delete（刪除）
改為 [DELETE] http://www.example.com/photo/logo

從而進一步規(guī)范了資源標(biāo)識的使用。

通過 REST 架構(gòu)，Web 應(yīng)用程序可以用一致的接口（URI）暴露資源給外部世界，并提供對資源的操作服務(wù)。這對于以資源為中心的 Web 應(yīng)用來說非常重要。例如照片共享網(wǎng)站、用戶社區(qū)等。

—————————————

Ruby On Rails 1.2 版對 REST 有很好的支持，但要在 PHP 中應(yīng)用 REST 還需要解決不少問題：

  • 如何在服務(wù)端判斷 PUT、DELETE 請求方法；
  • 如何獲取用 PUT、DELETE 請求方法中傳遞的數(shù)據(jù)；
  • 如何獲取 HTTP 請求頭信息中的 Accept 參數(shù)值；
  • 如何在瀏覽器端發(fā)起 PUT 和 DELETE 請求。

不過我仔細看了 PHP 文檔，我覺得上面幾個問題都是可以解決的。

服務(wù)端綜合使用 $_SERVER['HTTP_ACCEPT']、$_SERVER['REQUEST_URI']、$_SERVER['REQUEST_METHOD']、$_SERVER['QUERY_STRING'] 這些變量應(yīng)該可以搞定前面三個問題。而第四個問題則可以用 JavaScript 的 XMLHttpRequest 對象來實現(xiàn)。

不過我想 REST 的真正價值在于 Web Services，而不是通過瀏覽器操作的應(yīng)用程序。

—————————————

參考：