REST構架風格介紹：狀態表述轉移
REST(Representational State Transfer)是HTTP協議的作者Roy Fielding博士在其博士論文中提出的一種互聯網應用構架風格。與以遠程對象為核心的ORB和以服務為核心的SOA相比，以資源為核心的REST讓我們從嶄新的視角審視互聯網應用。REST為互聯網應用量身定做的簡潔模型、與HTTP協議的完美結合、構架的高擴展性，為互聯網應用構架設計和異構系統集成設計帶來了一股清新的空氣。
語言生態環境
計算機發展至今，產生了許許多多不同的語言，每種語言都定義了自己獨特的生態環境。在這個生態環境內的程序共享相同的類型系統、運行時環境、并發模型等。雖然所有程序的本質是相同的：從問題領域到機器領域的映射，但無法回避的是不同生態環境的程序很難跨越彼此的邊界。同樣是int，在A和B語言通常截然不同（CLR和JVM能部分解決類型共享問題），更不用說A語言具有但B語言不具有的某些語言特性(CLR和JVM沒法解決)。
當系統可以在單一的生態環境中自給自足時，跨越生態環境的問題并不存在；但在多數互聯網應用中，系統的各個部分通常既是生產者又是消費者，必須要打破生態環境的界限才能相互協作。比如，A公司的Service A，需要對外提供服務，而Service A又依賴于B公司的Service B和C公司的Service C；由于無法保證不同公司都采用同樣的語言，因此各服務的接口必須保證語言無關性。在我所了解的范圍內，有3種跨域生態環境的方式：
1. ORB(Object Request Broker)
以CORBA為代表，其核心概念是遠程對象（remote object）。熟悉.Net Remoting的朋友應該能體會其風格（需要說明的是.Net Remoting只跨越微軟的生態環境）。不同生態環境的程序可以像調用本地對象一樣調用遠程對象代理的方法，ORB會負責連接到遠程的對象，并處理數據的序列化與反序列化。
2. SOA
其核心概念是服務(Service)。比如：我們要提供整數加法Web服務，我們會很自然地想到通過類似下面的url來表達服務接口：
http://www.example.com/add?a=1&b=2
并通過xml結構表達結果：
3. REST
其核心概念是資源(Resource)。在REST的世界中，沒有服務的概念，同樣是上面的例子，在REST的世界中，http://www.example.com/add?a=1&b=2是一個xml網頁資源的id，而非服務的接口。所以，REST讓我們從資源的角度來審視互聯網應用并指導我們的設計，這是它與ORB和SOA最本質的區別。下面我們將更詳細的介紹，REST以資源為核心的模型和相應的設計風格。
狀態表述轉移
在REST的世界中，資源即狀態，而互聯網就是一個巨大的狀態機：每個網頁是其一個狀態；url是狀態的表述；REST風格的應用則是從一個狀態遷移到下一個狀態的狀態轉移過程。早期互聯網只有靜態頁面的時候，通過超鏈接在靜態網頁間瀏覽跳轉的page->link->page->link…模式就是一種典型的狀態轉移過程。
無狀態服務器
REST風格應用可以實現交互，但它卻天然地具有服務器無狀態的特征。在狀態遷移的過程中，服務器不需要記錄任何Session，所有的狀態都通過url的形式記錄在了客戶端。PS:更準確地說，這里的無狀態服務器，是指服務器不保存會話狀態(Session)；而資源本身則是天然的狀態，通常是需要被保存的；本文提到的無狀態服務器均指無會話狀態服務器。
舉個例子：一個心理測試的應用，需要用戶做2次選擇題，每次可選A、B兩種答案，2次選擇完畢之后將告知用戶屬于何種心理類型。
如果按ORB或SOA的服務思維，很容易想到在服務器端保存Session，每次選擇以后修改Session，根據Session產生結果。但如果以REST的狀態表述轉移模型為指導，我們會自然地得出這樣設計：
每一個頁面表示一個狀態（存在于客戶端），頁面包含了到下一個頁面的超鏈接，每當用戶選a或選b時分別轉移到下一個相應的狀態。這樣，所有的會話狀態其實都是通過url的形式保存在了客戶端，服務器端實現了無狀態。另外，需要說明的是，雖然上圖有7個狀態，但并非一定需要在服務器預先生成7個靜態頁面，它們完全可以是動態頁面，這不影響狀態轉移的概念模型以及服務器無狀態的特征。
有構架設計經驗的朋友應該很清楚，與有狀態服務設計相比，無狀態服務容易實現系統性能的橫向擴展。通過增加硬件，部署多個無狀態服務，并進行load balance不會受到制約；而有狀態服務模式，Session的存儲、共享都會帶來性能瓶頸，且無法通過增加硬件消除。
Google搜索就是一個典型的無狀態服務。試想一下，當你搜索“周杰倫”以后，Google提示你有數百萬的結果，并每10條一頁分成若干頁，Google會把結果保存進服務器Session嗎，然后當你翻頁的時候，再從Session中取嗎？顯然這樣龐大的Session，即使是Google也無法承受。來看看Google的url：
第一頁：http://www.google.cn/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=0&sa=N
第二頁：http://www.google.cn/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=10&sa=N
Google把搜索結果的每一頁視為資源（狀態），并通過url來表示，同一搜索關鍵字的不同分頁通過start參數來進行區分。當你從第一頁點擊第二頁的鏈接時，只是從一個狀態跳到了下一個狀態而已；對于Google而言，其實是一條新的查詢（按REST的觀點，獲取新的資源），而兩次查詢很可能是由不同的服務器在處理，而用戶卻感覺Google似乎記住了會話。
從上面的例子中，我們初步體會到了一點REST風格的味道。但需要說明，REST風格包含了無狀態服務器的特征；但反過來，并非具有無狀態服務器特征的都是REST。SOA同樣可以是無狀態的，REST的核心還是資源。
【編輯推薦】
