REST架構(gòu)風(fēng)格是全新的針對(duì)Web應(yīng)用的開(kāi)發(fā)風(fēng)格，是當(dāng)今世界最成功的互聯(lián)網(wǎng)超媒體分布式系統(tǒng)架構(gòu)，它使得人們真正理解了Http協(xié)議本來(lái)面貌。隨著 REST架構(gòu)成為主流技術(shù)，一種全新的互聯(lián)網(wǎng)網(wǎng)絡(luò)應(yīng)用開(kāi)發(fā)的思維方式開(kāi)始流行。
目前，51，校內(nèi)，海內(nèi)，阿里軟件等都通過(guò)REST架構(gòu)來(lái)實(shí)現(xiàn)平臺(tái)數(shù)據(jù)的開(kāi)放，與第三方的數(shù)據(jù)交換。REST已然成為sns開(kāi)放平臺(tái)的首要開(kāi)放標(biāo)準(zhǔn)。下面簡(jiǎn)單介紹一下REST的原理和使用準(zhǔn)則。
wiki介紹見(jiàn)此：http://en.wikipedia.org/wiki/Representational_State_Transfer
REST是什么
REST是英文Representational State Transfer的縮寫(xiě)，中文翻譯為“表述性狀態(tài)轉(zhuǎn)移”，他是由Roy Thomas Fielding博士在他的論文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個(gè)術(shù)語(yǔ)。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ù)器
無(wú)狀態(tài)性
-
無(wú) 狀態(tài)性是在客戶－服務(wù)器約束的基礎(chǔ)上添加的又一層規(guī)范。他要求通信必須在本質(zhì)上是無(wú)狀態(tài)的，即從客戶到服務(wù)器的每個(gè)request都必須包含理解該 request所必須的所有信息。這個(gè)規(guī)范改善了系統(tǒng)的可見(jiàn)性（無(wú)狀態(tài)性使得客戶端和服務(wù)器端不必保存對(duì)方的詳細(xì)信息，服務(wù)器只需要處理當(dāng)前 request，而不必了解所有的request歷史），可靠性（無(wú)狀態(tài)性減少了服務(wù)器從局部錯(cuò)誤中恢復(fù)的任務(wù)量），可伸縮性（無(wú)狀態(tài)性使得服務(wù)器端可以 很容易的釋放資源，因?yàn)榉?wù)器端不必在多個(gè)request中保存狀態(tài)）。同時(shí)，這種規(guī)范的缺點(diǎn)也是顯而易見(jiàn)得，由于不能將狀態(tài)數(shù)據(jù)保存在服務(wù)器上的共享上 下文中，因此增加了在一系列request中發(fā)送重復(fù)數(shù)據(jù)的開(kāi)銷,嚴(yán)重的降低了效率。
緩存
B/S架構(gòu)的優(yōu)點(diǎn)是其部署非常方便，但在用戶體驗(yàn)方面卻不是很理想。為了改善這種情況，我們引入了REST。
REST在原有的架構(gòu)上增加了三個(gè)新規(guī)范：統(tǒng)一接口，分層系統(tǒng)和按需代碼。
統(tǒng)一接口
分層系統(tǒng)
按需代碼
REST的設(shè)計(jì)準(zhǔn)則
REST架構(gòu)是針對(duì)Web應(yīng)用而設(shè)計(jì)的，其目的是為了降低開(kāi)發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST提出了如下設(shè)計(jì)準(zhǔn)則：
-
-
網(wǎng)絡(luò)上的所有事物都被抽象為資源（resource）；
-
每個(gè)資源對(duì)應(yīng)一個(gè)唯一的資源標(biāo)識(shí)符（resource identifier）；
-
通過(guò)通用的連接器接口（generic connector interface）對(duì)資源進(jìn)行操作；
-
對(duì)資源的各種操作不會(huì)改變資源標(biāo)識(shí)符；
-
所有的操作都是無(wú)狀態(tài)的（stateless）。
REST中的資源所指的不是數(shù)據(jù)，而是數(shù)據(jù)和表現(xiàn)形式的組合，比如“最新訪問(wèn)的10位會(huì)員”和“最活躍的10為會(huì)員”在 數(shù)據(jù)上可能有重疊或者完全相同，而 由于他們的表現(xiàn)形式不同，所以被歸為不同的資源，這也就是為什么REST的全名是Representational State Transfer的原因。資源標(biāo)識(shí)符就是URI(Uniform Resource Identifier)，不管是圖片，Word還是視頻文件，甚至只是一種虛擬的服務(wù)，也不管你是xml格式,txt文件格式還是其它文件格式，全部通過(guò) URI對(duì)資源進(jìn)行唯一的標(biāo)識(shí)。
REST是基于Http協(xié)議的，任何對(duì)資源的操作行為都是通過(guò)Http協(xié)議來(lái)實(shí)現(xiàn)。以往的Web開(kāi)發(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是沒(méi)有變化的，這和以往的 Web開(kāi)發(fā)有很大的區(qū)別。正由于這一點(diǎn)，極大的簡(jiǎn)化了Web開(kāi)發(fā)，也使得URI可以被設(shè)計(jì)成更為直觀的反映資源的結(jié)構(gòu)，這種URI的設(shè)計(jì)被稱作 RESTful的URI。這位開(kāi)發(fā)人員引入了一種新的思維方式：通過(guò)URL來(lái)設(shè)計(jì)系統(tǒng)結(jié)構(gòu)。當(dāng)然了，這種設(shè)計(jì)方式對(duì)一些特定情況也是不適用的，也就是說(shuō)不 是所有的URI都可以RESTful的。
REST 之所以可以提高系統(tǒng)的可伸縮性，就是因?yàn)樗笏械牟僮鞫际菬o(wú)狀態(tài)的。由于沒(méi)有了上下文(Context)的約束，做分布式和集群的時(shí)候就更為簡(jiǎn)單，也 可以讓系統(tǒng)更為有效的利用緩沖池(Pool）。并且由于服務(wù)器端不需要記錄客戶端的一系列訪問(wèn)，也減少了服務(wù)器端的性能。
使用REST架構(gòu)
對(duì)于開(kāi)發(fā)人員來(lái) 說(shuō)，關(guān)心的是如何使用REST架構(gòu)，這里我們來(lái)簡(jiǎn)單談?wù)勥@個(gè)問(wèn)題。REST不僅僅是一種嶄新的架構(gòu)，它帶來(lái)的更是一種全新的Web開(kāi)發(fā)過(guò)程中的思維方式： 通過(guò)URL來(lái)設(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)很相似，他是通過(guò)測(cè)試用例來(lái)設(shè)計(jì)系統(tǒng)的接口，每一個(gè)測(cè)試用例都表示一系列用戶的需求。開(kāi)發(fā)人員不需要一開(kāi)始就編寫(xiě)功能，而只需要 把需要實(shí)現(xiàn)的功能通過(guò)測(cè)試用例的形式表現(xiàn)出來(lái)即可。這個(gè)和REST中通過(guò)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)的概念上來(lái)看，所有能夠被抽象成資源的東西都可以被指定為一個(gè)URL，而開(kāi)發(fā)人員所需要做的工作就是如何能把用戶需求抽象為資源，以及如何抽 象的精確。因?yàn)閷?duì)資源抽象的越為精確，對(duì)REST的應(yīng)用來(lái)說(shuō)就越好。這個(gè)和傳統(tǒng)MVC開(kāi)發(fā)模式中基于Action的思想差別就非常大。設(shè)計(jì)良好的URL， 不但對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)可以更明確的認(rèn)識(shí)系統(tǒng)結(jié)構(gòu)，對(duì)使用者來(lái)說(shuō)也方便記憶和識(shí)別資源，因?yàn)閁RL足夠簡(jiǎn)單和有意義。按照以往的設(shè)計(jì)模式，很多URL后面都 是一堆參數(shù)，對(duì)于使用者來(lái)說(shuō)也是很不方便的。
既然REST這 么好用，那么是不是所有的Web應(yīng)用都能采取此種架構(gòu)呢？答案是否定的。我們知道，直到現(xiàn)在為止，MVC(Model-View-Controller) 模式依然是Web開(kāi)發(fā)最普遍的模式，絕大多數(shù)的公司和開(kāi)發(fā)人員都采取此種架構(gòu)來(lái)開(kāi)發(fā)Web應(yīng)用，并且其思維方式也停留于此。MVC模式由數(shù)據(jù)，視圖和控制 器構(gòu)成，通過(guò)事件(Event)觸發(fā)Controller來(lái)改變Model和View。加上Webwork,Struts等開(kāi)源框架的加入，MVC開(kāi)發(fā)模 式已經(jīng)相當(dāng)成熟，其思想根本就是基于Action來(lái)驅(qū)動(dòng)。從開(kāi)發(fā)人員角度上來(lái)說(shuō)，貿(mào)然接受一個(gè)新的架構(gòu)會(huì)帶來(lái)風(fēng)險(xiǎn)，其中的不確定因素太多。并且REST新 的思維方式是把所有用戶需求抽象為資源，這在實(shí)際開(kāi)發(fā)中是比較難做到的，因?yàn)椴⒉皇撬械挠脩粜枨蠖寄鼙怀橄鬄橘Y源，這樣也就是說(shuō)不是整個(gè)系統(tǒng)的結(jié)構(gòu)都能 通過(guò)REST的來(lái)表現(xiàn)。所以在開(kāi)發(fā)中，我們需要根據(jù)以上2點(diǎn)來(lái)在REST和MVC中做出選擇。我們認(rèn)為比較好的辦法是混用REST和MVC，因?yàn)檫@適合絕 大多數(shù)的Web應(yīng)用開(kāi)發(fā)，開(kāi)發(fā)人員只需要對(duì)比較容易能夠抽象為資源的用戶需求采取REST的開(kāi)發(fā)模式，而對(duì)其它需求采取MVC開(kāi)發(fā)即可。這里需要提到的就 是ROR(Ruby on Rails)框架，這是一個(gè)基于Ruby語(yǔ)言的越來(lái)越流行的Web開(kāi)發(fā)框架，它極大的提高了Web開(kāi)發(fā)的速度。更為重要的是，ROR(從1.2版本起)框 架是第一個(gè)引入REST做為核心思想的Web開(kāi)發(fā)框架，它提供了對(duì)REST最好的支持，也是當(dāng)今最成功的應(yīng)用REST的Web開(kāi)發(fā)框架。實(shí)際上，ROR的 REST實(shí)現(xiàn)就是REST和MVC混用，開(kāi)發(fā)人員采用ROR框架，可以更快更好的構(gòu)建Web應(yīng)用。
對(duì)開(kāi)發(fā)人員來(lái)說(shuō)，REST不僅僅在Web開(kāi)發(fā)上貢獻(xiàn)了自己的力量，同時(shí)也讓我們學(xué)到了如何把軟件工程原則系統(tǒng)地應(yīng)用于對(duì)一個(gè)真實(shí)軟件的設(shè)計(jì)和評(píng)估上