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