久久国产成人av_抖音国产毛片_a片网站免费观看_A片无码播放手机在线观看,色五月在线观看,亚洲精品m在线观看,女人自慰的免费网址,悠悠在线观看精品视频,一级日本片免费的,亚洲精品久,国产精品成人久久久久久久

分享

關(guān)于REST的一點(diǎn)想法,歡迎大家討論,。-rails-Ruby -JavaEye做最棒的軟件...

 openlog 2007-04-17
這陣子正打算用Rails做個東東,,所以開始系統(tǒng)地學(xué)習(xí)起了Rails。巧合的是,,大概兩周前,,dlee邀請我加入Fielding博士關(guān)于REST的那篇論文的翻譯團(tuán)隊(duì)??梢哉fRails和REST這兩個最熱門的詞匯幾乎同時擠入了我的生活,。隨著我對Rails的學(xué)習(xí)和對[Fielding]的翻譯,我也開始對REST產(chǎn)生了一些不太成熟的想法,,寫在這里與大家分享,同時也起到拋磚引玉的作用,,歡迎大家討論,。

先復(fù)習(xí)一下REST的基本思想。[Fielding]把REST形式化地定義為一種架構(gòu)風(fēng)格(architecture style),,它有架構(gòu)元素(element)和架構(gòu)約束(constraint)組成,。這些概念比較晦澀難懂,,而且我們做工程的往往并不需要形而上的理解。我們只知道,,REST是一種針對網(wǎng)絡(luò)應(yīng)用的設(shè)計(jì)和開發(fā)方式,,可以降低開發(fā)的復(fù)雜性,提高系統(tǒng)的可伸縮性,。REST提出了一些設(shè)計(jì)概念和準(zhǔn)則:
  1. 網(wǎng)絡(luò)上的所有事物都被抽象為資源(resource),;
  2. 每個資源對應(yīng)一個唯一的資源標(biāo)識(resource identifier);
  3. 通過通用的連接器接口(generic connector interface)對資源進(jìn)行操作,;
  4. 對資源的各種操作不會改變資源標(biāo)識,;
  5. 所有的操作都是無狀態(tài)的(stateless)。
對于當(dāng)今最常見的網(wǎng)絡(luò)應(yīng)用來說,,resource identifier是url,,generic connector interface是HTTP,第4條準(zhǔn)則就是我們常說的url不變性,。這些概念中的resouce最容易使人產(chǎn)生誤解,。resouce所指的并不是數(shù)據(jù),而是數(shù)據(jù)+特定的表現(xiàn)形式(representation),,這也是為什么REST的全名是Representational State Transfer的原因,。舉個例子來說,“本月賣得最好的10本書”和“你最喜歡的10本書”在數(shù)據(jù)上可能有重疊(有一本書即賣得好,,你又喜歡),,甚至完全相同。但是它們的representation不同,,因此是不同的resource,。

REST之所以能夠簡化開發(fā),是因?yàn)槠湟氲募軜?gòu)約束,,比如Rails 1.2中對REST的實(shí)現(xiàn)默認(rèn)把controller中的方法限制在7個:index,、show、new,、edit,、create、update和destory,,這實(shí)際上就是對CURD的實(shí)現(xiàn),。更進(jìn)一步講,Rails(也是當(dāng)今大部分網(wǎng)絡(luò)應(yīng)用)使用HTTP作為generic connector interface,,HTTP則把對一個url的操作限制在了4個之內(nèi):GET,、POST、PUT和DELETE。

REST之所以能夠提高系統(tǒng)的可伸縮性,,是因?yàn)樗鼜?qiáng)制所有操作都是stateless的,,這樣就沒有context的約束,如果要做分布式,、做集群,,就不需要考慮context的問題了。同時,,它令系統(tǒng)可以有效地使用pool,。REST對性能的另一個提升來自其對client和server任務(wù)的分配:server只負(fù)責(zé)提供resource以及操作resource的服務(wù),而client要根據(jù)resource中的data和representation自己做render,。這就減少了服務(wù)器的開銷,。

既然REST有這樣的好處,那我們應(yīng)該義無反顧地?fù)肀,?!目前一些大牛(像DHH)都已經(jīng)開始投入到了REST的世界,那我們這些人應(yīng)該做什么或者說思考寫什么你呢,?我覺得我們應(yīng)該思考兩個問題:
  1. 如何使用REST,;
  2. REST和MVC的關(guān)系。
第一個問題假設(shè)REST是我們應(yīng)該采用的架構(gòu),,然后討論如何使用,;第二個問題則要說明REST和當(dāng)前最普遍應(yīng)用的MVC是什么關(guān)系,互補(bǔ)還是取代,?

我們先來談?wù)劦谝粋€問題,,如何使用REST。我感覺,,REST除了給我們帶來了一個嶄新的架構(gòu)以外,,還有一個重要的貢獻(xiàn)是在開發(fā)系統(tǒng)過程中的一種新的思維方式:通過url來設(shè)計(jì)系統(tǒng)的結(jié)構(gòu)。根據(jù)REST,,每個url都代表一個resource,,而整個系統(tǒng)就是由這些resource組成的。因此,,如果url是設(shè)計(jì)良好的,,那么系統(tǒng)的結(jié)構(gòu)就也應(yīng)該是設(shè)計(jì)良好的。對于非高手級的開發(fā)人員來說,,考慮一個系統(tǒng)如何架構(gòu)總是一個很抽象的問題,。敏捷開發(fā)所提倡的Test Driven Development,其好處之一(我覺得是最大的好處)就是可以通過testcase直觀地設(shè)計(jì)系統(tǒng)的接口,。比如在還沒有創(chuàng)建一個class的時候就編寫一個testcase,,雖然設(shè)置不能通過編譯,,但是testcase中的方法調(diào)用可以很好地從class使用者的角度反映出需要的接口,從而為class的設(shè)計(jì)提供了直觀的表現(xiàn),。這與在REST架構(gòu)中通過url設(shè)計(jì)系統(tǒng)結(jié)構(gòu)非常類似。雖然我們連一個功能都沒有實(shí)現(xiàn),,但是我們可以先設(shè)計(jì)出我們認(rèn)為合理的url,,這些url甚至不能連接到任何page或action,但是它們直觀地告訴我們:系統(tǒng)對用戶的訪問接口就應(yīng)該是這樣,。根據(jù)這些url,,我們可以很方便地設(shè)計(jì)系統(tǒng)的結(jié)構(gòu)。

讓我在這里重申一遍:REST允許我們通過url設(shè)計(jì)系統(tǒng),,就像Test Driven Development允許我們使用testcase設(shè)計(jì)class接口一樣,。

OK,既然url有這樣的好處,,那我們就著重討論一下如何設(shè)計(jì)url,。網(wǎng)絡(luò)應(yīng)用通常都是有hierarchy的,像棵大樹,。我們通常希望url也能反映出資源的層次性,。比如對于一個blog應(yīng)用:/articles表示所有的文章,/articles/1表示id為1的文章,,這都比較直觀,。遺憾的是,網(wǎng)絡(luò)應(yīng)用的資源結(jié)構(gòu)永遠(yuǎn)不會如此簡單,。因此人們常常會問這樣一個問題:RESTful的url能覆蓋所有的用戶請求嗎,?比如,login如何RESTful,?search如何RESTful,?

從REST的概念上來看,所有可以被抽象為資源的東東都可以使用RESTful的url,。因此對于上面的兩個問題,,如果login和search可以被抽象為資源,那么就可以使用RESTful的url,。search比較簡單,,因?yàn)樗鼤祷厮阉鹘Y(jié)果,因此可以被抽象為資源,,并且只實(shí)現(xiàn)index方法就可以了(只需要顯示搜索結(jié)果,,沒有create、destory之類的東西),。然而這里面也有一個問題:search的關(guān)鍵字如何傳給server,?index方法顯然應(yīng)該使用HTTP GET,,這會把關(guān)鍵字加到url后面,當(dāng)然不符合REST的風(fēng)格,。要解決這個問題,,可以把每次search看作一個資源,因此要創(chuàng)建create和index方法,,create用來在用戶點(diǎn)擊“搜索”按鈕是通過HTTP POST把關(guān)鍵字傳給server,,然后index則用來顯示搜索結(jié)果。這樣一來,,我們還可以記錄用戶的搜索歷史,。使用同樣的方法,我們也可以對login應(yīng)用REST,,即每次login動作是一個資源,。

現(xiàn)在,我們來復(fù)雜一些的東東,。如何用url表達(dá)“category為ruby的article”,?一開始可能想到的是/category/ruby/articles,這種想法很直觀,。但是我覺得里面的category是不需要的,,我們可以直接把“/ruby”理解為“category是ruby”,也就是說“ruby”出現(xiàn)的位置說明了它指的就是category,。OK,,/ruby/articles,單單從這個url上看,,我們能獲得多少關(guān)于category的信息呢,?顯然category隱藏在了url后面,這樣做到底好不好,,應(yīng)該是仁者見仁,,智者見智了。對于如何表達(dá)category這樣的東西,,我還沒想出很好的方式,,大家有什么好idea,可以一起討論,。

另外還有一種url形式,,它對應(yīng)到程序中的繼承關(guān)系。比如product是一個父類,,book和computer是其子類,。那么所有產(chǎn)品的url應(yīng)該是/products,所有書籍的url應(yīng)該是/books,,所有電腦的url應(yīng)該是/computers,。這一想法就比較直觀了,,而且再次驗(yàn)證了url可以幫助我們進(jìn)行設(shè)計(jì)的論點(diǎn)。

讓我再說明一下我的想法:如果每個用戶需求都可以抽象為資源,,那么就可以完全使用REST,。

由此看來,使用REST的關(guān)鍵是如何抽象資源,,抽象得越精確,,對REST的應(yīng)用就越好。因此,,如何改變我們目前根深蒂固的基于action的思想是最重要的。

有了對第一個問題的討論,,第二個問題就容易討論多了,。REST會取代MVC嗎?還是彼此是互補(bǔ)關(guān)系(就像AOP對于OOP),?答案是It depends,!如果我們可以把所有的用戶需求都可以抽象為資源,那么MVC就可以推出歷史的舞臺了,。如果情況相反,,那么我們就需要混合使用REST和MVC。

當(dāng)然,,這是非常理想的論斷,。可能我們無法找到一種方法可以把所有的用戶需求都抽象為資源,,因?yàn)楸WC這種抽象的完整性(即真的是所有需求都可以)需要形式化的證明,。而且即使被證明出來了,由于開發(fā)人員的能力和喜好不同,,MVC肯定也會成為不少人的首選,。但是對于希望擁抱REST的人來說,這些都沒有關(guān)系,。只要你開發(fā)的系統(tǒng)所設(shè)計(jì)的問題域可以被合理地抽象為資源,,那么REST就會成為你的開發(fā)利器。

所以,,所有希望擁抱REST的朋友們,,趕快訓(xùn)練自己如何帶上資源的眼鏡看世界吧,這才是REST的核心所在,。

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點(diǎn),。請注意甄別內(nèi)容中的聯(lián)系方式,、誘導(dǎo)購買等信息,,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,,請點(diǎn)擊一鍵舉報(bào),。
    轉(zhuǎn)藏 分享 獻(xiàn)花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多