論REST架構(gòu)與傳統(tǒng)MVC
來源：程序員人生 發(fā)布時間：2015-02-06 08:30:44 閱讀次數(shù)：3613次
1前言 ：
由于 REST 可以下降開發(fā)的復(fù)雜度，提高系統(tǒng)的可伸縮性，增強系統(tǒng)的可擴大性，簡化利用系統(tǒng)之間的集成，因此得到了廣大開發(fā)人員的愛好，同時得到了業(yè)界廣泛的支持。比如 IBM，Google 等公司的很多產(chǎn)品都提供了 REST API 給開發(fā)人員；與此同時，大量的開源項目和云計算服務(wù)都提供了
REST API 接口。
而在最近，1些新產(chǎn)品的開發(fā)乃至已幾近完全拋棄了傳統(tǒng)的類似 JSP 的技術(shù)， 轉(zhuǎn)而大量使用 REST 風(fēng)格的構(gòu)架設(shè)計， 即在服務(wù)器端所有商業(yè)邏輯都以 REST API 的方式暴露給客戶端， 所有閱讀器用戶界面使用 widget，Ajax，HTML5
等技術(shù)，用 HTTP 的方式與后臺直接交互。
2：甚么是REST
REST是英文Representational State Transfer的縮寫，中文翻譯為“表述性狀態(tài)轉(zhuǎn)移”，他是由Roy
Thomas Fielding博士在他的論文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的1個術(shù)語。REST本身只是為散布式超媒體系統(tǒng)設(shè)計的1種架構(gòu)風(fēng)格，而不是標(biāo)準(zhǔn)。
基于Web的架構(gòu)，實際上就是各種規(guī)范的集合，這些規(guī)范共同組成了Web架構(gòu)。比如Http協(xié)議，比如客戶端服務(wù)器模式，這些都是規(guī)范。每當(dāng)我們在原有規(guī) 范的基礎(chǔ)上增加新的規(guī)范，就會構(gòu)成新的架構(gòu)。而REST正是這樣1種架構(gòu)，他結(jié)合了1系列的規(guī)范，而構(gòu)成了1種新的基于Web的架構(gòu)風(fēng)格。
3：REST規(guī)范
（1）客戶－
服務(wù)器
這類規(guī)范的提出，改良了用戶接口跨多個平臺的可移植性，并且通過簡化
服務(wù)器組件，改良了系統(tǒng)的可伸縮性。最為關(guān)鍵的是通過分離用戶接口和數(shù)據(jù)存儲這兩個關(guān)注點，使得不同用戶終端享受相同數(shù)據(jù)成了可能。
（2）無狀態(tài)性
無狀態(tài)性是在客戶－
服務(wù)器束縛的基礎(chǔ)上添加的又1層規(guī)范。他要求通訊必須在本質(zhì)上是無狀態(tài)的，即從客戶到
服務(wù)器的每一個request都必須包括理解該 request所必須的所有信息。這個規(guī)范改良了系統(tǒng)的可見性（無狀態(tài)性使得客戶端和
服務(wù)器端沒必要保存對方的詳細信息，
服務(wù)器只需要處應(yīng)當(dāng)前 request，而沒必要了解所有的request歷史），可靠性（無狀態(tài)性減少了
服務(wù)器從局部毛病中恢復(fù)的任務(wù)量），可伸縮性（無狀態(tài)性使得
服務(wù)器端可以 很容易的釋放資源，由于
服務(wù)器端沒必要在多個request中保存狀態(tài)）。同時，這類規(guī)范的缺點也是不言而喻得，由于不能將狀態(tài)數(shù)據(jù)保存在
服務(wù)器上的同享上
下文中，因此增加了在1系列request中發(fā)送重復(fù)數(shù)據(jù)的開消,嚴(yán)重的下降了效力。
（3）緩存
為 了改良無狀態(tài)性帶來的網(wǎng)絡(luò)的低效性，我們填加了緩存束縛。緩存束縛允許隱式或顯式地標(biāo)記1個response中的數(shù)據(jù)，這樣就賦予了客戶端緩存 response數(shù)據(jù)的功能，這樣就能夠為以后的request共用緩存的數(shù)據(jù)，部份或全部的消除1部份交互，增加了網(wǎng)絡(luò)的效力。但是用于客戶端緩存了信 息，也就同時增加了客戶端與
服務(wù)器數(shù)據(jù)不1致的可能，從而下降了可靠性。
B/S架構(gòu)的優(yōu)點是其部署非常方便，但在用戶體驗方面卻不是很理想。為了改良這類情況，我們引入了REST。
REST在原本的架構(gòu)上增加了3個新規(guī)范：統(tǒng)1接口，分層系統(tǒng)和按需代碼。
（4）統(tǒng)1接口
REST 架構(gòu)風(fēng)格的核心特點就是強調(diào)組件之間有1個統(tǒng)1的接口，這表現(xiàn)在REST世界里，網(wǎng)絡(luò)上所有的事物都被抽象為資源，而REST就是通過通用的鏈接器接口對 資源進行操作。這樣設(shè)計的好處是保證系統(tǒng)提供的服務(wù)都是解耦的，極大的簡化了系統(tǒng)，從而改良了系統(tǒng)的交互性和可重用性。并且REST針對Web的常見情況 做了優(yōu)化，使得REST接口被設(shè)計為可以高效的轉(zhuǎn)移大粒度的超媒體數(shù)據(jù)，這也就致使了REST接口對其它的架構(gòu)其實不是最優(yōu)的。
（5）分層系統(tǒng)
分層系統(tǒng)規(guī)則的加入提高了各種層次之間的獨立性，為全部系統(tǒng)的復(fù)雜性設(shè)置了邊界，通過封裝遺留的服務(wù)，使新的
服務(wù)器免受遺留客戶真?zhèn)€影響，這也就提高了系統(tǒng)的可伸縮性。
（6）按需代碼
REST允許對客戶端功能進行擴大。比如，通過下載并履行applet或腳本情勢的代碼，來擴大客戶端功能。但這在改良系統(tǒng)可擴大性的同時，也下降了可見性。所以它只是REST的1個可選的束縛。
4： REST的設(shè)計準(zhǔn)則
REST架構(gòu)是針對Web利用而設(shè)計的，其目的是為了下降開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST提出了以下設(shè)計準(zhǔn)則：
網(wǎng)絡(luò)上的所有事物都被抽象為資源（resource）；
每一個資源對應(yīng)1個唯1的資源標(biāo)識符（resource identifier）；
通過通用的連接器接口（generic connector interface）對資源進行操作；
對資源的各種操作不會改變資源標(biāo)識符；
所有的操作都是無狀態(tài)的（stateless）。
REST中的資源所指的不是數(shù)據(jù)，而是數(shù)據(jù)和表現(xiàn)情勢的組合，比如“最新訪問的10位會員”和“最活躍的10為會員”在數(shù)據(jù)上可能有堆疊或完全相同，而 由于他們的表現(xiàn)情勢不同，所以被歸為不同的資源，這也就是為何REST的全名是Representational State Transfer的緣由。資源標(biāo)識符就是URI(Uniform Resource Identifier)，不論是圖片，Word還是視頻文件，乃至只是1種虛擬的服務(wù)，也不管你是xml格式,txt文件格式還是其它文件格式，全部通過 URI對資源進行唯1的標(biāo)識。
REST是基于Http協(xié)議的，任何對資源的操作行動都是通過Http協(xié)議來實現(xiàn)。以往的Web開發(fā)大多數(shù)用的都是Http協(xié)議中的GET和POST方 法，對其他方法很少使用，這實際上是由于對Http協(xié)議認識片面的理解釀成的。Http不單單是1個簡單的運載數(shù)據(jù)的協(xié)議，而是1個具有豐富內(nèi)涵的網(wǎng)絡(luò)軟 件的協(xié)議。他不單單能對互聯(lián)網(wǎng)資源進行唯1定位，而且還能告知我們?nèi)绾螌υ撡Y源進行操作。Http把對1個資源的操作限制在4個方法之內(nèi)：GET, POST,PUT和DELETE，這正是對資源CRUD操作的實現(xiàn)。由于資源和URI是逐一對應(yīng)的，履行這些操作的時候URI是沒有變化的，這和以往的
Web開發(fā)有很大的區(qū)分。正由于這1點，極大的簡化了Web開發(fā)，也使得URI可以被設(shè)計成更加直觀的反應(yīng)資源的結(jié)構(gòu)，這類URI的設(shè)計被稱作 RESTful的URI。這位開發(fā)人員引入了1種新的思惟方式：通過URL來設(shè)計系統(tǒng)結(jié)構(gòu)。固然了，這類設(shè)計方式對1些特定情況也是不適用的，也就是說不 是所有的URI都可以RESTful的。
REST 之所以可以提高系統(tǒng)的可伸縮性，就是由于它要求所有的操作都是無狀態(tài)的。由于沒有了上下文(Context)的束縛，做散布式和集群的時候就更加簡單，也 可讓系統(tǒng)更加有效的利用緩沖池(Pool）。并且由于
服務(wù)器端不需要記錄客戶真?zhèn)€1系列訪問，也減少了
服務(wù)器真?zhèn)€性能。
5：如何使用REST
對開發(fā)人員來 說，關(guān)心的是如何使用REST架構(gòu)，這里我們來簡單談?wù)勥@個問題。REST不單單是1種嶄新的架構(gòu)，它帶來的更是1種全新的Web開發(fā)進程中的思惟方式：
通過URL來設(shè)計系統(tǒng)結(jié)構(gòu)。在REST中，所有的URL都對應(yīng)著資源，只要URL的設(shè)計是良好的，那末其顯現(xiàn)的系統(tǒng)結(jié)構(gòu)也就是良好的。這點和TDD (Test Driven Development)很相似，他是通過測試用例來設(shè)計系統(tǒng)的接口，每個測試用例都表示1系列用戶的需求。開發(fā)人員不需要1開始就編寫功能，而只需要
把需要實現(xiàn)的功能通過測試用例的情勢表現(xiàn)出來便可。這個和REST中通過URL設(shè)計系統(tǒng)結(jié)構(gòu)的方式類似，我們只需要根據(jù)需求設(shè)計出公道地URL，這些 URL不1定非要鏈接到指定的頁面或完成1些行動，只要它們能夠直觀的表現(xiàn)出系統(tǒng)的用戶接口。根據(jù)這些URL，我們就能夠方便的設(shè)計系統(tǒng)結(jié)構(gòu)。從 REST架構(gòu)的概念上來看，所有能夠被抽象成資源的東西都可以被指定為1個URL，而開發(fā)人員所需要做的工作就是如何能把用戶需求抽象為資源，和如何抽 象的精確。由于對資源抽象的越為精確，對REST的利用來講就越好。這個和傳統(tǒng)MVC開發(fā)模式中基于Action的思想差別就非常大。設(shè)計良好的URL，
不但對開發(fā)人員來講可以更明確的認識系統(tǒng)結(jié)構(gòu)，對使用者來講也方便記憶和辨認資源，由于URL足夠簡單和成心義。依照以往的設(shè)計模式，很多URL后面都 是1堆參數(shù)，對使用者來講也是很不方便的。
6：REST和MVC的選擇
既然REST這 么好用，那末是否是所有的Web利用都能采取此種架構(gòu)呢？答案是不是定的。我們知道，直到現(xiàn)在為止，MVC(Model-View-Controller)
模式仍然是Web開發(fā)最普遍的模式，絕大多數(shù)的公司和開發(fā)人員都采取此種架構(gòu)來開發(fā)Web利用，并且其思惟方式也停留于此。MVC模式由數(shù)據(jù)，視圖和控制 器構(gòu)成，通過事件(Event)觸發(fā)Controller來改變Model和View。加上Webwork,Struts等開源框架的加入，MVC開發(fā)模
式已相當(dāng)做熟，其思想根本就是基于Action來驅(qū)動。從開發(fā)人員角度上來講，冒然接受1個新的架構(gòu)會帶來風(fēng)險，其中的不肯定因素太多。并且REST新
的思惟方式是把所有用戶需求抽象為資源，這在實際開發(fā)中是比較難做到的，由于其實不是所有的用戶需求都能被抽象為資源，這樣也就是說不是全部系統(tǒng)的結(jié)構(gòu)都能 通過REST的來表現(xiàn)。所以在開發(fā)中，我們需要根據(jù)以上2點來在REST和MVC中做出選擇。我們認為比較好的辦法是混用REST和MVC，由于這合適絕
大多數(shù)的Web利用開發(fā)，開發(fā)人員只需要對照較容易能夠抽象為資源的用戶需求采取REST的開發(fā)模式，而對其它需求采取MVC開發(fā)便可。這里需要提到的就 是ROR(Ruby on Rails)框架，這是1個基于Ruby語言的愈來愈流行的Web開發(fā)框架，它極大的提高了Web開發(fā)的速度。更加重要的是，ROR(從1.2版本起)框 架是第1個引入REST做為核心思想的Web開發(fā)框架，它提供了對REST最好的支持，也是現(xiàn)今最成功的利用REST的Web開發(fā)框架。實際上，ROR的 REST實現(xiàn)就是REST和MVC混用，開發(fā)人員采取ROR框架，可以更快更好的構(gòu)建Web利用。
生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機掃描二維碼進行捐贈
