[轉(zhuǎn)]REST 協(xié)議的認(rèn)識(shí) 客戶端服務(wù)端例子

轉(zhuǎn)自 REST 協(xié)議的認(rèn)識(shí) 客戶端服務(wù)端例子

1、協(xié)議介紹:
轉(zhuǎn) http://blog.csdn.net/colorfulbinary/article/details/6657184
REST架構(gòu)風(fēng)格是全新的針對(duì)Web應(yīng)用的開發(fā)風(fēng)格,是當(dāng)今世界最成功的互聯(lián)網(wǎng)超媒體分布式系統(tǒng)架構(gòu),它使得人們真正理解了Http協(xié)議本來面貌。隨著 REST架構(gòu)成為主流技術(shù),一種全新的互聯(lián)網(wǎng)網(wǎng)絡(luò)應(yīng)用開發(fā)的思維方式開始流行。

目前,51,校內(nèi),海內(nèi),阿里軟件等都通過REST架構(gòu)來實(shí)現(xiàn)平臺(tái)數(shù)據(jù)的開放,與第三方的數(shù)據(jù)交換。REST已然成為sns開放平臺(tái)的首要開放標(biāo)準(zhǔn)。下面簡(jiǎn)單介紹一下REST的原理和使用準(zhǔn)則。

wiki介紹見此:http://en.wikipedia.org/wiki/Representational_State_Transfer

REST是什么

REST是英文Representational State Transfer的縮寫,中文翻譯為“表述性狀態(tài)轉(zhuǎn)移”,他是由Roy Thomas Fielding博士在他的論文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個(gè)術(shù)語。REST本身只是為分布式超媒體系統(tǒng)設(shè)計(jì)的一種架構(gòu)風(fēng)格,而不是標(biāo)準(zhǔn)。

基于Web的架構(gòu),實(shí)際上就是各種規(guī)范的集合,這些規(guī)范共同組成了Web架構(gòu)。比如Http協(xié)議,比如客戶端服務(wù)器模式,這些都是規(guī)范。每當(dāng)我們?cè)谠幸?guī) 范的基礎(chǔ)上增加新的規(guī)范,就會(huì)形成新的架構(gòu)。而REST正是這樣一種架構(gòu),他結(jié)合了一系列的規(guī)范,而形成了一種新的基于Web的架構(gòu)風(fēng)格。

傳統(tǒng)的Web應(yīng)用大都是B/S架構(gòu),它包括了如下一些規(guī)范 。

客戶-服務(wù)器

這種規(guī)范的提出,改善了用戶接口跨多個(gè)平臺(tái)的可移植性,并且通過簡(jiǎn)化服務(wù)器組件,改善了系統(tǒng)的可伸縮性。最為關(guān)鍵的是通過分離用戶接口和數(shù)據(jù)存儲(chǔ)這兩個(gè)關(guān)注點(diǎn),使得不同用戶終端享受相同數(shù)據(jù)成為了可能。
無狀態(tài)性

無 狀態(tài)性是在客戶-服務(wù)器約束的基礎(chǔ)上添加的又一層規(guī)范。他要求通信必須在本質(zhì)上是無狀態(tài)的,即從客戶到服務(wù)器的每個(gè)request都必須包含理解該 request所必須的所有信息。這個(gè)規(guī)范改善了系統(tǒng)的可見性(無狀態(tài)性使得客戶端和服務(wù)器端不必保存對(duì)方的詳細(xì)信息,服務(wù)器只需要處理當(dāng)前 request,而不必了解所有的request歷史),可靠性(無狀態(tài)性減少了服務(wù)器從局部錯(cuò)誤中恢復(fù)的任務(wù)量),可伸縮性(無狀態(tài)性使得服務(wù)器端可以 很容易的釋放資源,因?yàn)榉?wù)器端不必在多個(gè)request中保存狀態(tài))。同時(shí),這種規(guī)范的缺點(diǎn)也是顯而易見得,由于不能將狀態(tài)數(shù)據(jù)保存在服務(wù)器上的共享上 下文中,因此增加了在一系列request中發(fā)送重復(fù)數(shù)據(jù)的開銷,嚴(yán)重的降低了效率。
緩存

為 了改善無狀態(tài)性帶來的網(wǎng)絡(luò)的低效性,我們填加了緩存約束。緩存約束允許隱式或顯式地標(biāo)記一個(gè)response中的數(shù)據(jù),這樣就賦予了客戶端緩存 response數(shù)據(jù)的功能,這樣就可以為以后的request共用緩存的數(shù)據(jù),部分或全部的消除一部分交互,增加了網(wǎng)絡(luò)的效率。但是用于客戶端緩存了信 息,也就同時(shí)增加了客戶端與服務(wù)器數(shù)據(jù)不一致的可能,從而降低了可靠性。
B/S架構(gòu)的優(yōu)點(diǎn)是其部署非常方便,但在用戶體驗(yàn)方面卻不是很理想。為了改善這種情況,我們引入了REST。

REST在原有的架構(gòu)上增加了三個(gè)新規(guī)范:統(tǒng)一接口,分層系統(tǒng)和按需代碼。

統(tǒng)一接口

REST 架構(gòu)風(fēng)格的核心特征就是強(qiáng)調(diào)組件之間有一個(gè)統(tǒng)一的接口,這表現(xiàn)在REST世界里,網(wǎng)絡(luò)上所有的事物都被抽象為資源,而REST就是通過通用的鏈接器接口對(duì) 資源進(jìn)行操作。這樣設(shè)計(jì)的好處是保證系統(tǒng)提供的服務(wù)都是解耦的,極大的簡(jiǎn)化了系統(tǒng),從而改善了系統(tǒng)的交互性和可重用性。并且REST針對(duì)Web的常見情況 做了優(yōu)化,使得REST接口被設(shè)計(jì)為可以高效的轉(zhuǎn)移大粒度的超媒體數(shù)據(jù),這也就導(dǎo)致了REST接口對(duì)其它的架構(gòu)并不是最優(yōu)的。
分層系統(tǒng)

分層系統(tǒng)規(guī)則的加入提高了各種層次之間的獨(dú)立性,為整個(gè)系統(tǒng)的復(fù)雜性設(shè)置了邊界,通過封裝遺留的服務(wù),使新的服務(wù)器免受遺留客戶端的影響,這也就提高了系統(tǒng)的可伸縮性。
按需代碼

REST允許對(duì)客戶端功能進(jìn)行擴(kuò)展。比如,通過下載并執(zhí)行applet或腳本形式的代碼,來擴(kuò)展客戶端功能。但這在改善系統(tǒng)可擴(kuò)展性的同時(shí),也降低了可見性。所以它只是REST的一個(gè)可選的約束。
REST的設(shè)計(jì)準(zhǔn)則

REST架構(gòu)是針對(duì)Web應(yīng)用而設(shè)計(jì)的,其目的是為了降低開發(fā)的復(fù)雜性,提高系統(tǒng)的可伸縮性。REST提出了如下設(shè)計(jì)準(zhǔn)則:

網(wǎng)絡(luò)上的所有事物都被抽象為資源(resource);
每個(gè)資源對(duì)應(yīng)一個(gè)唯一的資源標(biāo)識(shí)符(resource identifier);
通過通用的連接器接口(generic connector interface)對(duì)資源進(jìn)行操作;
對(duì)資源的各種操作不會(huì)改變資源標(biāo)識(shí)符;
所有的操作都是無狀態(tài)的(stateless)。
REST中的資源所指的不是數(shù)據(jù),而是數(shù)據(jù)和表現(xiàn)形式的組合,比如“最新訪問的10位會(huì)員”和“最活躍的10為會(huì)員”在數(shù)據(jù)上可能有重疊或者完全相同,而 由于他們的表現(xiàn)形式不同,所以被歸為不同的資源,這也就是為什么REST的全名是Representational State Transfer的原因。資源標(biāo)識(shí)符就是URI(Uniform Resource Identifier),不管是圖片,Word還是視頻文件,甚至只是一種虛擬的服務(wù),也不管你是xml格式,txt文件格式還是其它文件格式,全部通過 URI對(duì)資源進(jìn)行唯一的標(biāo)識(shí)。

REST是基于Http協(xié)議的,任何對(duì)資源的操作行為都是通過Http協(xié)議來實(shí)現(xiàn)。以往的Web開發(fā)大多數(shù)用的都是Http協(xié)議中的GET和POST方 法,對(duì)其他方法很少使用,這實(shí)際上是因?yàn)閷?duì)Http協(xié)議認(rèn)識(shí)片面的理解造成的。Http不僅僅是一個(gè)簡(jiǎn)單的運(yùn)載數(shù)據(jù)的協(xié)議,而是一個(gè)具有豐富內(nèi)涵的網(wǎng)絡(luò)軟 件的協(xié)議。他不僅僅能對(duì)互聯(lián)網(wǎng)資源進(jìn)行唯一定位,而且還能告訴我們?nèi)绾螌?duì)該資源進(jìn)行操作。Http把對(duì)一個(gè)資源的操作限制在4個(gè)方法以內(nèi):GET, POST,PUT和DELETE,這正是對(duì)資源CRUD操作的實(shí)現(xiàn)。由于資源和URI是一一對(duì)應(yīng)的,執(zhí)行這些操作的時(shí)候URI是沒有變化的,這和以往的 Web開發(fā)有很大的區(qū)別。正由于這一點(diǎn),極大的簡(jiǎn)化了Web開發(fā),也使得URI可以被設(shè)計(jì)成更為直觀的反映資源的結(jié)構(gòu),這種URI的設(shè)計(jì)被稱作 RESTful的URI。這位開發(fā)人員引入了一種新的思維方式:通過URL來設(shè)計(jì)系統(tǒng)結(jié)構(gòu)。當(dāng)然了,這種設(shè)計(jì)方式對(duì)一些特定情況也是不適用的,也就是說不 是所有的URI都可以RESTful的。

REST 之所以可以提高系統(tǒng)的可伸縮性,就是因?yàn)樗笏械牟僮鞫际菬o狀態(tài)的。由于沒有了上下文(Context)的約束,做分布式和集群的時(shí)候就更為簡(jiǎn)單,也 可以讓系統(tǒng)更為有效的利用緩沖池(Pool)。并且由于服務(wù)器端不需要記錄客戶端的一系列訪問,也減少了服務(wù)器端的性能。

使用REST架構(gòu)

對(duì)于開發(fā)人員來 說,關(guān)心的是如何使用REST架構(gòu),這里我們來簡(jiǎn)單談?wù)勥@個(gè)問題。REST不僅僅是一種嶄新的架構(gòu),它帶來的更是一種全新的Web開發(fā)過程中的思維方式: 通過URL來設(shè)計(jì)系統(tǒng)結(jié)構(gòu)。在REST中,所有的URL都對(duì)應(yīng)著資源,只要URL的設(shè)計(jì)是良好的,那么其呈現(xiàn)的系統(tǒng)結(jié)構(gòu)也就是良好的。這點(diǎn)和TDD (Test Driven Development)很相似,他是通過測(cè)試用例來設(shè)計(jì)系統(tǒng)的接口,每一個(gè)測(cè)試用例都表示一系列用戶的需求。開發(fā)人員不需要一開始就編寫功能,而只需要 把需要實(shí)現(xiàn)的功能通過測(cè)試用例的形式表現(xiàn)出來即可。這個(gè)和REST中通過URL設(shè)計(jì)系統(tǒng)結(jié)構(gòu)的方式類似,我們只需要根據(jù)需求設(shè)計(jì)出合理地URL,這些 URL不一定非要鏈接到指定的頁(yè)面或者完成一些行為,只要它們能夠直觀的表現(xiàn)出系統(tǒng)的用戶接口。根據(jù)這些URL,我們就可以方便的設(shè)計(jì)系統(tǒng)結(jié)構(gòu)。從 REST架構(gòu)的概念上來看,所有能夠被抽象成資源的東西都可以被指定為一個(gè)URL,而開發(fā)人員所需要做的工作就是如何能把用戶需求抽象為資源,以及如何抽 象的精確。因?yàn)閷?duì)資源抽象的越為精確,對(duì)REST的應(yīng)用來說就越好。這個(gè)和傳統(tǒng)MVC開發(fā)模式中基于Action的思想差別就非常大。設(shè)計(jì)良好的URL, 不但對(duì)于開發(fā)人員來說可以更明確的認(rèn)識(shí)系統(tǒng)結(jié)構(gòu),對(duì)使用者來說也方便記憶和識(shí)別資源,因?yàn)閁RL足夠簡(jiǎn)單和有意義。按照以往的設(shè)計(jì)模式,很多URL后面都 是一堆參數(shù),對(duì)于使用者來說也是很不方便的。

既然REST這 么好用,那么是不是所有的Web應(yīng)用都能采取此種架構(gòu)呢?答案是否定的。我們知道,直到現(xiàn)在為止,MVC(Model-View-Controller) 模式依然是Web開發(fā)最普遍的模式,絕大多數(shù)的公司和開發(fā)人員都采取此種架構(gòu)來開發(fā)Web應(yīng)用,并且其思維方式也停留于此。MVC模式由數(shù)據(jù),視圖和控制 器構(gòu)成,通過事件(Event)觸發(fā)Controller來改變Model和View。加上Webwork,Struts等開源框架的加入,MVC開發(fā)模 式已經(jīng)相當(dāng)成熟,其思想根本就是基于Action來驅(qū)動(dòng)。從開發(fā)人員角度上來說,貿(mào)然接受一個(gè)新的架構(gòu)會(huì)帶來風(fēng)險(xiǎn),其中的不確定因素太多。并且REST新 的思維方式是把所有用戶需求抽象為資源,這在實(shí)際開發(fā)中是比較難做到的,因?yàn)椴⒉皇撬械挠脩粜枨蠖寄鼙怀橄鬄橘Y源,這樣也就是說不是整個(gè)系統(tǒng)的結(jié)構(gòu)都能 通過REST的來表現(xiàn)。所以在開發(fā)中,我們需要根據(jù)以上2點(diǎn)來在REST和MVC中做出選擇。我們認(rèn)為比較好的辦法是混用REST和MVC,因?yàn)檫@適合絕 大多數(shù)的Web應(yīng)用開發(fā),開發(fā)人員只需要對(duì)比較容易能夠抽象為資源的用戶需求采取REST的開發(fā)模式,而對(duì)其它需求采取MVC開發(fā)即可。這里需要提到的就 是ROR(Ruby on Rails)框架,這是一個(gè)基于Ruby語言的越來越流行的Web開發(fā)框架,它極大的提高了Web開發(fā)的速度。更為重要的是,ROR(從1.2版本起)框 架是第一個(gè)引入REST做為核心思想的Web開發(fā)框架,它提供了對(duì)REST最好的支持,也是當(dāng)今最成功的應(yīng)用REST的Web開發(fā)框架。實(shí)際上,ROR的 REST實(shí)現(xiàn)就是REST和MVC混用,開發(fā)人員采用ROR框架,可以更快更好的構(gòu)建Web應(yīng)用。

對(duì)開發(fā)人員來說,REST不僅僅在Web開發(fā)上貢獻(xiàn)了自己的力量,同時(shí)也讓我們學(xué)到了如何把軟件工程原則系統(tǒng)地應(yīng)用于對(duì)一個(gè)真實(shí)軟件的設(shè)計(jì)和評(píng)估上

2、談?wù)勛约簩?duì)REST的認(rèn)識(shí)
REST協(xié)議其實(shí)和其他的soap協(xié)議大致相同,
服務(wù)端:有點(diǎn)類似于我們所知道的servlet服務(wù)
客戶端:可以使用get 、post帶上xml的結(jié)構(gòu)體 于服務(wù)端進(jìn)行通訊

網(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/
以下對(duì)這些框架進(jìn)行了較為全面的分析。
Restlet,最新版本1.0.1
特點(diǎn):完全拋棄了Servlet API,作為替代,自己實(shí)現(xiàn)了一套API。能夠支持復(fù)雜的REST架構(gòu)設(shè)計(jì)。
缺點(diǎn):

  1. 雖然也可以運(yùn)行于Web容器中,但是難以利用Servlet和JSP等資源。因?yàn)樾枰硗鈱W(xué)習(xí)一套API和概念,學(xué)習(xí)成本比較高。
  2. 完全不支持服務(wù)器端的HTTP Session,強(qiáng)制完全基于無狀態(tài)服務(wù)器模型來做開發(fā)。對(duì)于基于瀏覽器的應(yīng)用來說,開發(fā)難度較高。
  3. 自身沒有包括與Spring的集成,可以使用第三方代碼與Spring集成,集成難度較大。
  4. 文檔不是很豐富,大多比較簡(jiǎn)短,很多時(shí)候需要自己去讀代碼,或者到其wiki上去查找。
  5. 沒有內(nèi)建的國(guó)際化支持。
    優(yōu)點(diǎn):
  6. 有內(nèi)建的HTTP認(rèn)證機(jī)制,不需要另外開發(fā)安全機(jī)制。
  7. 靈活性較高,支持更多的REST概念,支持透明的內(nèi)容協(xié)商,適合于開發(fā)更加強(qiáng)大的REST組件(不限于服務(wù)器端應(yīng)用)。
  8. 零配置文件,全部配置通過代碼來完成。
    相關(guān)資源:
    功能列表:http://www.restlet.org/about/features
    簡(jiǎn)介:http://www.restlet.org/about/introduction
    教程:http://www.restlet.org/documentation/1.0/tutorial
    FAQ:http://www.restlet.org/about/faq
    Cetia4,最新版本1.0
    特點(diǎn):基于Servlet API開發(fā),可以運(yùn)行于所有的Web容器中。
    優(yōu)點(diǎn):
  9. 可以充分利用Servlet API和JSP等資源,需要額外學(xué)習(xí)的概念較少,學(xué)習(xí)成本較低。
  10. 對(duì)于傳統(tǒng)的Web應(yīng)用,可以使用服務(wù)器端HTTP Session;對(duì)于Web服務(wù)類應(yīng)用,不使用HTTP Session,基于無狀態(tài)服務(wù)器模型做開發(fā)。
  11. 自身包括了對(duì)于Web MVC的支持,熟悉Web MVC框架的開發(fā)者很容易理解。還內(nèi)建了參數(shù)映射、參數(shù)驗(yàn)證等等傳統(tǒng)Web MVC框架所支持的功能。
  12. 內(nèi)建了自己特有的導(dǎo)航對(duì)象棧的概念,對(duì)于支持傳統(tǒng)的Web應(yīng)用的開發(fā)(基于瀏覽器的導(dǎo)航)非常有幫助。
  13. 提供了JSP標(biāo)簽庫(kù),對(duì)于傳統(tǒng)的基于HTML表單的Web開發(fā)非常有幫助。
  14. 支持與SiteMesh相配合,由SiteMesh來支持頁(yè)面布局的重用。
  15. 內(nèi)建有與Spring的集成,集成起來非常容易。
  16. 配置文件完全基于標(biāo)準(zhǔn)的web.xml,不需要額外的配置文件。大量使用默認(rèn)配置,一般情況下足以滿足常見的需求。
  17. 擁有很好的文檔。
  18. 有內(nèi)建的國(guó)際化支持。
    缺點(diǎn):
  19. 沒有內(nèi)建的HTTP認(rèn)證機(jī)制,需要自行開發(fā)安全機(jī)制。
  20. 對(duì)于內(nèi)容協(xié)商的支持比較弱,僅支持HTML和XML格式的表現(xiàn)。需要加以擴(kuò)展才能支持其他格式的表現(xiàn)。
    相關(guān)資源:
    教程:https://cetia4.dev.java.net/files/documents/5545/38989/cetia4_tutorial.pdf
    Axis2,最新版本1.2
    特點(diǎn):同時(shí)支持SOAP和REST風(fēng)格的Web Service。
    缺點(diǎn):
  21. 僅僅支持GET與POST方法。
  22. 僅僅是以REST風(fēng)格暴露出Web服務(wù),數(shù)據(jù)格式仍然是包含SOAP封裝的XML,不能使用更加有效的格式。
  23. 只支持同步的調(diào)用方式。
  24. 僅僅提供了以SOAP方式暴露Web服務(wù)的最小化的支持,不支持全面的REST架構(gòu)設(shè)計(jì)。
    相關(guān)資源:
    簡(jiǎn)介:http://ws.apache.org/axis2/1_2/rest-ws.html
    sqlREST,最新版本0.3.1
    特點(diǎn):
  25. 為任何可以通過JDBC訪問的數(shù)據(jù)庫(kù)提供Web服務(wù)訪問接口,自動(dòng)將REST風(fēng)格的HTTP請(qǐng)求轉(zhuǎn)換為相應(yīng)的數(shù)據(jù)庫(kù)SQL語句,并將數(shù)據(jù)庫(kù)中的記錄編碼為XML格式傳給客戶端。是REST風(fēng)格的HTTP請(qǐng)求到數(shù)據(jù)庫(kù)中的數(shù)據(jù)的直接映射。
  26. 基于Servlet API開發(fā)。
    缺點(diǎn):
  27. 因?yàn)槭荝EST風(fēng)格的HTTP請(qǐng)求到SQL語句的直接映射,因此強(qiáng)制使用以SQL和關(guān)系數(shù)據(jù)庫(kù)為中心的數(shù)據(jù)建模設(shè)計(jì)方法,不支持面向?qū)ο蟮脑O(shè)計(jì)。靈活性很低,難以實(shí)現(xiàn)較為復(fù)雜的業(yè)務(wù)邏輯。
  28. 因?yàn)橘Y源的定義僅限于數(shù)據(jù)庫(kù)的表,難以實(shí)現(xiàn)更高層次的抽象,必然會(huì)導(dǎo)致非常細(xì)粒度的API。應(yīng)用的性能和可伸縮性都難以保證。
    相關(guān)資源:
    教程:http://sqlrest.sourceforge.net/5-minutes-guide.htm
    REST-art,最新版本0.2
    特點(diǎn):一個(gè)旨在替換復(fù)雜的SOAP框架的REST框架,用來作為替代SOAP方便地發(fā)布Web服務(wù)的工具。不是基于Servlet API開發(fā)。
    缺點(diǎn):
  29. 目前尚處于剛剛起步的階段,功能非常少。
  30. 不是基于Servlet API,帶來了額外的學(xué)習(xí)成本。
    相關(guān)資源:
    教程:http://sourceforge.net/docman/index.php?group_id=175132

3、相關(guān)代碼:
從網(wǎng)上下載了幾個(gè)開源框架,最后決定使用sqlrest-1.0.zip ,在sqlrest基礎(chǔ)上進(jìn)行了點(diǎn)小改造

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

推薦閱讀更多精彩內(nèi)容