1.1　解讀REST

REST（Representational State Transfer，表述性狀態轉移），源于REST之父Roy Thomas Fielding博士在2000年就讀加州大學歐文分校期間發表的一篇學術論文——《Architectural Styles and the Design of Network-based Software Architectures》。論文中提出了REST的6個特點，分別是：客戶端-服務器的、無狀態的、可緩存的、統一接口、分層系統和按需編碼。在此不敢“班門弄斧”，希望讀者閱讀一下這部開山之作，以此理解REST產生的原因和特點。

REST具有跨平臺、跨語言的優勢。從其誕生開始，廣泛地得到了諸多語言的快速支持，比較著名的是ROR（Ruby on Rails）。ROR非常強調規約大于配置的理念，這一理念被諸多框架和工具支持——包括以Python領域的Django、Groovy領域的Grails為代表的框架，以及Maven、Gradle為代表的構建工具等，但REST本身只規定了面向資源，并沒有包含如何定義和約束一個資源的標準。因此要提示讀者，很多實現了REST的框架和工具所具備的特質，其全部特征未必都是REST定義的，包括本書要講的JAX-RS標準的定義和Jersey等JAX-RS的實現。

REST在眾多平臺和語言上的支持，不僅包括上述列舉的傳統編程語言、腳本語言，還包括Node.js這樣新興的服務器端腳本語言。REST的無狀態，代理友好性等優勢，使對其支持的實現更加方便和簡潔。

1.1.1　一種架構風格

REST是一種架構風格。在REST架構風格中，對象被抽象為一種資源（resource），資源的命名使用概念清晰的名詞來定義。表述性狀態是對資源數據在某個瞬間狀態的快照，資源的某個瞬時狀態被定義為一種表述（representation），這種描述性的狀態包括資源數據的內容、表述格式（比如XML、JSON、Atom）等信息，一種資源可以對應多種表述。REST的資源是可尋址的，通過HTTP協議（RFC 2616）定義的通用動詞方法（比如GET、PUT、DELETE、POST），并使用URI協議（RFC 3305）來唯一標識某個資源公布出來的接口。請求一個資源的過程可以理解為，訪問一個具有指定性和描述性的URI，經由HTTP，將資源的表述從服務器轉移到客戶端，或者相反方向。

REST不是一種技術（technology），也不是一個標準（standard）或協議（protocol），它使用既有標準：HTTP+URI+XML，來實現其要求的架構風格。因此，與之對應的不是SOAP，而是像RPC這樣的架構風格。

1.1.2　基本實現形式

HTTP+URI+XML是REST的基本實現形式，但不是唯一的實現形式。REST從推出時就使用已有的HTTP協議、URI協議來描述，而對如何使用一種編程語言來實現，并沒有進行任何描述和規定，甚至對于REST應該包含哪些傳輸類型或者數據格式也沒有描述，但通常的實現至少包含XML格式。具體而言，HTTP協議和URI用于統一接口和定位資源，文本、二進制流、XML和JSON等格式用來作為資源的表述。正如采用已有技術XMLHttpRequest+JavaScript+XML（XML后來幾乎被JSON替代）實現AJAX一樣，使用HTTP+URI+XML實現REST的好處是讓開發者持有這些已知的技術來開發REST，入門門檻較低，關注點更容易放到REST的核心概念和業務邏輯上。

這里要提示讀者的是，以HTTP+URI+XML實現的應用并不一定是REST式的，但對于AJAX，這個逆命題（以XMLHttpRequest+JavaScript+XML實現的應用一定是AJAX應用）是成立的。因為AJAX是一種“技術流派”，而REST是一種架構風格。學習和使用REST的關鍵是掌握這種思想，而不是具體的實現形式。