1、協(xié)議介紹：
轉 http://blog.csdn.net/colorfulbinary/article/details/6657184
REST架構風格是全新的針對Web應用的開發(fā)風格，是當今世界最成功的互聯(lián)網(wǎng)超媒體分布式系統(tǒng)架構，它使得人們真正理解了Http協(xié)議本來面貌。隨著 REST架構成為主流技術，一種全新的互聯(lián)網(wǎng)網(wǎng)絡應用開發(fā)的思維方式開始流行。
目前，51，校內(nèi)，海內(nèi)，阿里軟件等都通過REST架構來實現(xiàn)平臺數(shù)據(jù)的開放，與第三方的數(shù)據(jù)交換。REST已然成為sns開放平臺的首要開放標準。下面簡單介紹一下REST的原理和使用準則。
wiki介紹見此：http://en.wikipedia.org/wiki/Representational_State_Transfer
REST是什么
REST是英文Representational State Transfer的縮寫，中文翻譯為“表述性狀態(tài)轉移”，他是由Roy Thomas Fielding博士在他的論文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個術語。REST本身只是為分布式超媒體系統(tǒng)設計的一種架構風格，而不是標準。
基于Web的架構，實際上就是各種規(guī)范的集合，這些規(guī)范共同組成了Web架構。比如Http協(xié)議，比如客戶端服務器模式，這些都是規(guī)范。每當我們在原有規(guī) 范的基礎上增加新的規(guī)范，就會形成新的架構。而REST正是這樣一種架構，他結合了一系列的規(guī)范，而形成了一種新的基于Web的架構風格。
傳統(tǒng)的Web應用大都是B/S架構，它包括了如下一些規(guī)范 。
客戶－服務器
這種規(guī)范的提出，改善了用戶接口跨多個平臺的可移植性，并且通過簡化服務器組件，改善了系統(tǒng)的可伸縮性。最為關鍵的是通過分離用戶接口和數(shù)據(jù)存儲這兩個關注點，使得不同用戶終端享受相同數(shù)據(jù)成為了可能。
無狀態(tài)性
無 狀態(tài)性是在客戶－服務器約束的基礎上添加的又一層規(guī)范。他要求通信必須在本質上是無狀態(tài)的，即從客戶到服務器的每個request都必須包含理解該 request所必須的所有信息。這個規(guī)范改善了系統(tǒng)的可見性（無狀態(tài)性使得客戶端和服務器端不必保存對方的詳細信息，服務器只需要處理當前 request，而不必了解所有的request歷史），可靠性（無狀態(tài)性減少了服務器從局部錯誤中恢復的任務量），可伸縮性（無狀態(tài)性使得服務器端可以 很容易的釋放資源，因為服務器端不必在多個request中保存狀態(tài)）。同時，這種規(guī)范的缺點也是顯而易見得，由于不能將狀態(tài)數(shù)據(jù)保存在服務器上的共享上 下文中，因此增加了在一系列request中發(fā)送重復數(shù)據(jù)的開銷,嚴重的降低了效率。
緩存
為 了改善無狀態(tài)性帶來的網(wǎng)絡的低效性，我們填加了緩存約束。緩存約束允許隱式或顯式地標記一個response中的數(shù)據(jù)，這樣就賦予了客戶端緩存 response數(shù)據(jù)的功能，這樣就可以為以后的request共用緩存的數(shù)據(jù)，部分或全部的消除一部分交互，增加了網(wǎng)絡的效率。但是用于客戶端緩存了信 息，也就同時增加了客戶端與服務器數(shù)據(jù)不一致的可能，從而降低了可靠性。
B/S架構的優(yōu)點是其部署非常方便，但在用戶體驗方面卻不是很理想。為了改善這種情況，我們引入了REST。
REST在原有的架構上增加了三個新規(guī)范：統(tǒng)一接口，分層系統(tǒng)和按需代碼。
統(tǒng)一接口
REST 架構風格的核心特征就是強調(diào)組件之間有一個統(tǒng)一的接口，這表現(xiàn)在REST世界里，網(wǎng)絡上所有的事物都被抽象為資源，而REST就是通過通用的鏈接器接口對 資源進行操作。這樣設計的好處是保證系統(tǒng)提供的服務都是解耦的，極大的簡化了系統(tǒng)，從而改善了系統(tǒng)的交互性和可重用性。并且REST針對Web的常見情況 做了優(yōu)化，使得REST接口被設計為可以高效的轉移大粒度的超媒體數(shù)據(jù)，這也就導致了REST接口對其它的架構并不是最優(yōu)的。
分層系統(tǒng)
分層系統(tǒng)規(guī)則的加入提高了各種層次之間的獨立性，為整個系統(tǒng)的復雜性設置了邊界，通過封裝遺留的服務，使新的服務器免受遺留客戶端的影響，這也就提高了系統(tǒng)的可伸縮性。
按需代碼
REST允許對客戶端功能進行擴展。比如，通過下載并執(zhí)行applet或腳本形式的代碼，來擴展客戶端功能。但這在改善系統(tǒng)可擴展性的同時，也降低了可見性。所以它只是REST的一個可選的約束。
REST的設計準則
REST架構是針對Web應用而設計的，其目的是為了降低開發(fā)的復雜性，提高系統(tǒng)的可伸縮性。REST提出了如下設計準則：
網(wǎng)絡上的所有事物都被抽象為資源（resource）；
每個資源對應一個唯一的資源標識符（resource identifier）；
通過通用的連接器接口（generic connector interface）對資源進行操作；
對資源的各種操作不會改變資源標識符；
所有的操作都是無狀態(tài)的（stateless）。
REST中的資源所指的不是數(shù)據(jù)，而是數(shù)據(jù)和表現(xiàn)形式的組合，比如“最新訪問的10位會員”和“最活躍的10為會員”在數(shù)據(jù)上可能有重疊或者完全相同，而 由于他們的表現(xiàn)形式不同，所以被歸為不同的資源，這也就是為什么REST的全名是Representational State Transfer的原因。資源標識符就是URI(Uniform Resource Identifier)，不管是圖片，Word還是視頻文件，甚至只是一種虛擬的服務，也不管你是xml格式,txt文件格式還是其它文件格式，全部通過 URI對資源進行唯一的標識。
REST是基于Http協(xié)議的，任何對資源的操作行為都是通過Http協(xié)議來實現(xiàn)。以往的Web開發(fā)大多數(shù)用的都是Http協(xié)議中的GET和POST方 法，對其他方法很少使用，這實際上是因為對Http協(xié)議認識片面的理解造成的。Http不僅僅是一個簡單的運載數(shù)據(jù)的協(xié)議，而是一個具有豐富內(nèi)涵的網(wǎng)絡軟 件的協(xié)議。他不僅僅能對互聯(lián)網(wǎng)資源進行唯一定位，而且還能告訴我們?nèi)绾螌υ撡Y源進行操作。Http把對一個資源的操作限制在4個方法以內(nèi)：GET, POST,PUT和DELETE，這正是對資源CRUD操作的實現(xiàn)。由于資源和URI是一一對應的，執(zhí)行這些操作的時候URI是沒有變化的，這和以往的 Web開發(fā)有很大的區(qū)別。正由于這一點，極大的簡化了Web開發(fā)，也使得URI可以被設計成更為直觀的反映資源的結構，這種URI的設計被稱作 RESTful的URI。這位開發(fā)人員引入了一種新的思維方式：通過URL來設計系統(tǒng)結構。當然了，這種設計方式對一些特定情況也是不適用的，也就是說不 是所有的URI都可以RESTful的。
REST 之所以可以提高系統(tǒng)的可伸縮性，就是因為它要求所有的操作都是無狀態(tài)的。由于沒有了上下文(Context)的約束，做分布式和集群的時候就更為簡單，也 可以讓系統(tǒng)更為有效的利用緩沖池(Pool）。并且由于服務器端不需要記錄客戶端的一系列訪問，也減少了服務器端的性能。
使用REST架構
對于開發(fā)人員來 說，關心的是如何使用REST架構，這里我們來簡單談談這個問題。REST不僅僅是一種嶄新的架構，它帶來的更是一種全新的Web開發(fā)過程中的思維方式： 通過URL來設計系統(tǒng)結構。在REST中，所有的URL都對應著資源，只要URL的設計是良好的，那么其呈現(xiàn)的系統(tǒng)結構也就是良好的。這點和TDD (Test Driven Development)很相似，他是通過測試用例來設計系統(tǒng)的接口，每一個測試用例都表示一系列用戶的需求。開發(fā)人員不需要一開始就編寫功能，而只需要 把需要實現(xiàn)的功能通過測試用例的形式表現(xiàn)出來即可。這個和REST中通過URL設計系統(tǒng)結構的方式類似，我們只需要根據(jù)需求設計出合理地URL，這些 URL不一定非要鏈接到指定的頁面或者完成一些行為，只要它們能夠直觀的表現(xiàn)出系統(tǒng)的用戶接口。根據(jù)這些URL，我們就可以方便的設計系統(tǒng)結構。從 REST架構的概念上來看，所有能夠被抽象成資源的東西都可以被指定為一個URL，而開發(fā)人員所需要做的工作就是如何能把用戶需求抽象為資源，以及如何抽 象的精確。因為對資源抽象的越為精確，對REST的應用來說就越好。這個和傳統(tǒng)MVC開發(fā)模式中基于Action的思想差別就非常大。設計良好的URL， 不但對于開發(fā)人員來說可以更明確的認識系統(tǒng)結構，對使用者來說也方便記憶和識別資源，因為URL足夠簡單和有意義。按照以往的設計模式，很多URL后面都 是一堆參數(shù)，對于使用者來說也是很不方便的。
既然REST這 么好用，那么是不是所有的Web應用都能采取此種架構呢？答案是否定的。我們知道，直到現(xiàn)在為止，MVC(Model-View-Controller) 模式依然是Web開發(fā)最普遍的模式，絕大多數(shù)的公司和開發(fā)人員都采取此種架構來開發(fā)Web應用，并且其思維方式也停留于此。MVC模式由數(shù)據(jù)，視圖和控制 器構成，通過事件(Event)觸發(fā)Controller來改變Model和View。加上Webwork,Struts等開源框架的加入，MVC開發(fā)模 式已經(jīng)相當成熟，其思想根本就是基于Action來驅動。從開發(fā)人員角度上來說，貿(mào)然接受一個新的架構會帶來風險，其中的不確定因素太多。并且REST新 的思維方式是把所有用戶需求抽象為資源，這在實際開發(fā)中是比較難做到的，因為并不是所有的用戶需求都能被抽象為資源，這樣也就是說不是整個系統(tǒng)的結構都能 通過REST的來表現(xiàn)。所以在開發(fā)中，我們需要根據(jù)以上2點來在REST和MVC中做出選擇。我們認為比較好的辦法是混用REST和MVC，因為這適合絕 大多數(shù)的Web應用開發(fā)，開發(fā)人員只需要對比較容易能夠抽象為資源的用戶需求采取REST的開發(fā)模式，而對其它需求采取MVC開發(fā)即可。這里需要提到的就 是ROR(Ruby on Rails)框架，這是一個基于Ruby語言的越來越流行的Web開發(fā)框架，它極大的提高了Web開發(fā)的速度。更為重要的是，ROR(從1.2版本起)框 架是第一個引入REST做為核心思想的Web開發(fā)框架，它提供了對REST最好的支持，也是當今最成功的應用REST的Web開發(fā)框架。實際上，ROR的 REST實現(xiàn)就是REST和MVC混用，開發(fā)人員采用ROR框架，可以更快更好的構建Web應用。
對開發(fā)人員來說，REST不僅僅在Web開發(fā)上貢獻了自己的力量，同時也讓我們學到了如何把軟件工程原則系統(tǒng)地應用于對一個真實軟件的設計和評估上
2、談談自己對REST的認識
REST協(xié)議其實和其他的soap協(xié)議大致相同，
服務端：有點類似于我們所知道的servlet服務
客戶端：可以使用get 、post帶上xml的結構體 于服務端進行通訊
網(wǎng)上開源的REST框架也有很多 ，如Restlet 、RichRest 、RESTEasy 、sqlrest-1.0
框架介紹：http://blog.163.com/java_moon/blog/static/13333826420091110105010510/
目前宣稱支持REST的Java框架包括以下這些：
Restlet（http://www.restlet.org/）
Cetia4（https://cetia4.dev.java.net/）
Apache Axis2（http://http://ws.apache.org/axis2/）
sqlREST（http://sqlrest.sourceforge.net/）
REST-art（http://rest-art.sourceforge.net/）
以下對這些框架進行了較為全面的分析。
Restlet，最新版本1.0.1
特點：完全拋棄了Servlet API，作為替代，自己實現(xiàn)了一套API。能夠支持復雜的REST架構設計。
缺點：
- 雖然也可以運行于Web容器中，但是難以利用Servlet和JSP等資源。因為需要另外學習一套API和概念，學習成本比較高。
- 完全不支持服務器端的HTTP Session，強制完全基于無狀態(tài)服務器模型來做開發(fā)。對于基于瀏覽器的應用來說，開發(fā)難度較高。
- 自身沒有包括與Spring的集成，可以使用第三方代碼與Spring集成，集成難度較大。
- 文檔不是很豐富，大多比較簡短，很多時候需要自己去讀代碼，或者到其wiki上去查找。
- 沒有內(nèi)建的國際化支持。
優(yōu)點： - 有內(nèi)建的HTTP認證機制，不需要另外開發(fā)安全機制。
- 靈活性較高，支持更多的REST概念，支持透明的內(nèi)容協(xié)商，適合于開發(fā)更加強大的REST組件（不限于服務器端應用）。
- 零配置文件，全部配置通過代碼來完成。
相關資源：
功能列表：http://www.restlet.org/about/features
簡介：http://www.restlet.org/about/introduction
教程：http://www.restlet.org/documentation/1.0/tutorial
FAQ：http://www.restlet.org/about/faq
Cetia4，最新版本1.0
特點：基于Servlet API開發(fā)，可以運行于所有的Web容器中。
優(yōu)點： - 可以充分利用Servlet API和JSP等資源，需要額外學習的概念較少，學習成本較低。
- 對于傳統(tǒng)的Web應用，可以使用服務器端HTTP Session；對于Web服務類應用，不使用HTTP Session，基于無狀態(tài)服務器模型做開發(fā)。
- 自身包括了對于Web MVC的支持，熟悉Web MVC框架的開發(fā)者很容易理解。還內(nèi)建了參數(shù)映射、參數(shù)驗證等等傳統(tǒng)Web MVC框架所支持的功能。
- 內(nèi)建了自己特有的導航對象棧的概念，對于支持傳統(tǒng)的Web應用的開發(fā)（基于瀏覽器的導航）非常有幫助。
- 提供了JSP標簽庫，對于傳統(tǒng)的基于HTML表單的Web開發(fā)非常有幫助。
- 支持與SiteMesh相配合，由SiteMesh來支持頁面布局的重用。
- 內(nèi)建有與Spring的集成，集成起來非常容易。
- 配置文件完全基于標準的web.xml，不需要額外的配置文件。大量使用默認配置，一般情況下足以滿足常見的需求。
- 擁有很好的文檔。
- 有內(nèi)建的國際化支持。
缺點： - 沒有內(nèi)建的HTTP認證機制，需要自行開發(fā)安全機制。
- 對于內(nèi)容協(xié)商的支持比較弱，僅支持HTML和XML格式的表現(xiàn)。需要加以擴展才能支持其他格式的表現(xiàn)。
相關資源：
教程：https://cetia4.dev.java.net/files/documents/5545/38989/cetia4_tutorial.pdf
Axis2，最新版本1.2
特點：同時支持SOAP和REST風格的Web Service。
缺點： - 僅僅支持GET與POST方法。
- 僅僅是以REST風格暴露出Web服務，數(shù)據(jù)格式仍然是包含SOAP封裝的XML，不能使用更加有效的格式。
- 只支持同步的調(diào)用方式。
- 僅僅提供了以SOAP方式暴露Web服務的最小化的支持，不支持全面的REST架構設計。
相關資源：
簡介：http://ws.apache.org/axis2/1_2/rest-ws.html
sqlREST，最新版本0.3.1
特點： - 為任何可以通過JDBC訪問的數(shù)據(jù)庫提供Web服務訪問接口，自動將REST風格的HTTP請求轉換為相應的數(shù)據(jù)庫SQL語句，并將數(shù)據(jù)庫中的記錄編碼為XML格式傳給客戶端。是REST風格的HTTP請求到數(shù)據(jù)庫中的數(shù)據(jù)的直接映射。
- 基于Servlet API開發(fā)。
缺點： - 因為是REST風格的HTTP請求到SQL語句的直接映射，因此強制使用以SQL和關系數(shù)據(jù)庫為中心的數(shù)據(jù)建模設計方法，不支持面向對象的設計。靈活性很低，難以實現(xiàn)較為復雜的業(yè)務邏輯。
- 因為資源的定義僅限于數(shù)據(jù)庫的表，難以實現(xiàn)更高層次的抽象，必然會導致非常細粒度的API。應用的性能和可伸縮性都難以保證。
相關資源：
教程：http://sqlrest.sourceforge.net/5-minutes-guide.htm
REST-art，最新版本0.2
特點：一個旨在替換復雜的SOAP框架的REST框架，用來作為替代SOAP方便地發(fā)布Web服務的工具。不是基于Servlet API開發(fā)。
缺點： - 目前尚處于剛剛起步的階段，功能非常少。
- 不是基于Servlet API，帶來了額外的學習成本。
相關資源：
教程：http://sourceforge.net/docman/index.php?group_id=175132
3、相關代碼：
從網(wǎng)上下載了幾個開源框架，最后決定使用sqlrest-1.0.zip ，在sqlrest基礎上進行了點小改造
