每日一得

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

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

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

前面的內容比較枯燥，我說說我自己的理解。

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

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

REST 首先只是一種架構樣式，不是一種標準。這點和 Ajax 類似，兩者都是利用現有的成熟技術。

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

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

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

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

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

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

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

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

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

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

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

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

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

因為我們的 HTTP 請求頭信息有不同的狀態，從而可以獲得不同的數據，所以叫做“具象狀態傳輸”

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

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

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

• POST: 創建
• GET: 讀取
• PUT: 更新
• DELETE: 刪除

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

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

http://www.example.com/photo/logo/create（創建）
改為 [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

從而進一步規范了資源標識的使用。

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

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

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

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

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

服務端綜合使用 $_SERVER[’HTTP_ACCEPT’]、$_SERVER[’REQUEST_URI’]、$_SERVER[’REQUEST_METHOD’]、$_SERVER[’QUERY_STRING’] 這些變量應該可以搞定前面三個問題。而第四個問題則可以用 JavaScript 的 XMLHttpRequest 對象來實現。

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

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

參考：

• 面向資源與面向活動的 Web 服務
• 跨越邊界: REST on Rails
• Ajax 和 REST，第 1 部分
• Building Web Services the REST Way
• Architectural Styles and the Design of Network-based Software Architectures
• SIP/IMS網絡中的Representational State Transfer (REST)和數據分布