REST 是由 Roy Fielding 在他的論文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個術語。
REST 是英文 Representational State Transfer 的縮寫，有中文翻譯為“具象狀態(tài)傳輸”（參考：《SIP/IMS網絡中的Representational State Transfer (REST)和數(shù)據分布》）。
—————————————
前面的內容比較枯燥，我說說我自己的理解。
但是 REST 到底是什么呢？論文我看不懂，不過找到一篇更簡單易懂的東西：《Building Web Services the REST Way》。
根據這篇文章，我整理了一下我自己對 REST 的理解：
REST 首先只是一種架構樣式，不是一種標準。這點和 Ajax 類似，兩者都是利用現(xiàn)有的成熟技術。
在 REST 的定義中，一個 Web 應用總是使用固定的 URI 向外部世界呈現(xiàn)（或者說暴露）一個資源。
URI 是英文 Uniform Resource Identifier 的縮寫，中文翻譯“通用資源標志符”。
“通用資源標志符”是指唯一標識一個資源（xhtml 文件、圖片、css 樣式表）的字符串。當然了，RFC 中定義的 URI 復雜得多，不過我們此處將 URI 想象成一個人的身份證號碼就行了（你不能有兩個同時有效的身份證號碼，一個號碼也不可能同時對應兩個人）。而我們天天掛在嘴邊的 URL 地址就是 URI 的一種表現(xiàn)形式（個人理解，有錯請糾正）。
知道什么是 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 是服務器端的一個動態(tài)腳本文件，根據 name 參數(shù)生成 xhtml 文檔返回給瀏覽器。
現(xiàn)在假設我們要獲取這張照片的 XML 文檔。XML 文檔中包含照片的文件名、文件大小、拍攝日期等等信息。也就是說我們要獲取“同一個資源的不同表現(xiàn)形式的數(shù)據”。對于這個要求，我們可以很容易的用另一個 URL 地址達到：http://www.example.com/xml/logo。
但是，這就違背了“URI 唯一標識一個資源”的定義。如果我們要獲取同一個資源的多種表現(xiàn)形式，那么就要使用更多的 URL，從而給一個資源指定了多個不同的 URI。
而在 REST 中，不管是獲取照片的 xhtml 文檔還是 XML 文檔，或者照片文件本身，都是用同一個 URI，就是 http://www.example.com/photo/logo。
那這是怎么辦到的呢？Ruby On Rails 中是通過分辨 HTTP Request Header 信息來分辨客戶端是想要取得資源的哪一種表現(xiàn)形式的數(shù)據。
當我們用瀏覽器訪問一個網址時，瀏覽器會構造一個 HTTP 請求。這個請求有一個頭信息，其中包括了本次請求接受何種類型的數(shù)據。通常瀏覽器發(fā)送的 HTTP 請求頭中，Accept 的值都是 */*，也就說接受服務器返回的任何類型的數(shù)據。
看到這里，聰明的家伙應該知道了。只要我們指定一個特定的 Accept 參數(shù)，那么服務器就可以通過判斷該參數(shù)來決定返回什么類型的數(shù)據。所以在一個采用 REST 架構的應用中，要獲取同一個資源的不同表現(xiàn)形式的數(shù)據，只需要使用不同的 HTTP 請求頭信息就行了。
如果考慮為 Web 應用增加 Web Services，這種技術的價值就體現(xiàn)出來了。比如我寫了一個 Delphi 程序，現(xiàn)在只需要構造一個包含 Accept: text/xml 的 HTTP 請求頭，然后將請求發(fā)送到 http://www.example.com/photo/logo 就可以了。返回的結果就是一個 XML 文檔，而不是 xhtml 文檔。
因為我們的 HTTP 請求頭信息有不同的狀態(tài)，從而可以獲得不同的數(shù)據，所以叫做“具象狀態(tài)傳輸” 
—————————————
除了上面的用法，REST 還有進一步的擴展。
我們在 Web 應用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構中，用不同的 HTTP 請求方法來處理對資源的 CRUD（創(chuàng)建、讀取、更新和刪除）操作：
- POST: 創(chuàng)建
- GET: 讀取
- PUT: 更新
- DELETE: 刪除
經過這樣的一番擴展，我們對一個資源的 CRUD 操作就可以通過同一個 URI 完成了：
http://www.example.com/photo/logo（讀?。?br />仍然保持為 [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ī)范了資源標識的使用。
通過 REST 架構，Web 應用程序可以用一致的接口（URI）暴露資源給外部世界，并提供對資源的操作服務。這對于以資源為中心的 Web 應用來說非常重要。例如照片共享網站、用戶社區(qū)等。
—————————————
Ruby On Rails 1.2 版對 REST 有很好的支持，但要在 PHP 中應用 REST 還需要解決不少問題：
- 如何在服務端判斷 PUT、DELETE 請求方法；
- 如何獲取用 PUT、DELETE 請求方法中傳遞的數(shù)據；
- 如何獲取 HTTP 請求頭信息中的 Accept 參數(shù)值；
- 如何在瀏覽器端發(fā)起 PUT 和 DELETE 請求。
不過我仔細看了 PHP 文檔，我覺得上面幾個問題都是可以解決的。
服務端綜合使用 $_SERVER[’HTTP_ACCEPT’]、$_SERVER[’REQUEST_URI’]、$_SERVER[’REQUEST_METHOD’]、$_SERVER[’QUERY_STRING’] 這些變量應該可以搞定前面三個問題。而第四個問題則可以用 JavaScript 的 XMLHttpRequest 對象來實現(xiàn)。
不過我想 REST 的真正價值在于 Web Services，而不是通過瀏覽器操作的應用程序。
—————————————
參考：