|
記得有一位朋友曾經(jīng)問過我這樣一個(gè)問題:是不是無論傳遞什么東西都靠URI參數(shù)來做,就一定是符合REST風(fēng)格的。我當(dāng)時(shí)沒有完全理解他的意思,便給了他一個(gè)現(xiàn)在看來不甚滿意的回復(fù)。后來當(dāng)我理解他的意思后,仔細(xì)考慮了產(chǎn)生這個(gè)問題的原因,覺得這是由于對在REST中URL所承擔(dān)職責(zé)的一些誤解造成的,那么在閑話REST的第二篇里我就來談?wù)凴EST中資源的標(biāo)識與發(fā)現(xiàn)。我會(huì)將自己對基于HTTP和URI的REST架構(gòu)實(shí)現(xiàn)中資源標(biāo)識符的理解和認(rèn)識與大家分享,包括URI在REST中的角色和作用以及怎樣去看待查詢字符串,同時(shí)也希望能借此機(jī)會(huì)給那位朋友一個(gè)滿意的解釋。另外,由于“基于HTTP和URI的REST架構(gòu)實(shí)現(xiàn)”這個(gè)名稱過于羅嗦(盡管它是準(zhǔn)確的說法),本文接下來提到REST便是特指這一實(shí)現(xiàn),然而正像我在前一篇里所說的,REST是一組設(shè)計(jì)需求集合,它作為一個(gè)抽象層面的架構(gòu)風(fēng)格不依賴于任何實(shí)現(xiàn)細(xì)節(jié)。
REST是面向資源的,而每個(gè)資源之所以被稱作為資源是因?yàn)樗麄兡軌虮蛔R別和利用,這便是統(tǒng)一資源標(biāo)識符(Universal Resource Identifier)被設(shè)計(jì)和如此命名的緣由。URI是網(wǎng)絡(luò)上任何一個(gè)對象的名字,而它也僅僅是一個(gè)名字而已。URI的功能也正像人名一樣,我們可以到公安局通過姓名查找一個(gè)人的詳細(xì)信息,可以用人名來在與朋友的聊天中指代一個(gè)人,而對于這個(gè)名字的擁有者來說,他通過名字讓別人知道了他的存在,也給了別人稱呼他的方法。到網(wǎng)絡(luò)世界里,URI就好比是資源的名字,它被用來標(biāo)識、引用和查找資源,與現(xiàn)實(shí)世界中人名不同的是在網(wǎng)絡(luò)上URI不會(huì)重復(fù)。一個(gè)人可以有多個(gè)名字,同樣的一個(gè)資源也可以有多個(gè)指向它的URI,但是在假設(shè)不存在同名同姓的情況下,一個(gè)名字只能指代一個(gè)人,所以一個(gè)URI不允許同時(shí)指向兩個(gè)資源。
URI中的查詢字符串也許是誤解產(chǎn)生的根源,從表面上看他們似乎將引用一個(gè)URI看作是遠(yuǎn)程過程調(diào)用的一個(gè)便利寫法。雖然在我們過去基于RPC的編程模式下,這樣的認(rèn)識更加自然,但這卻違背了URI設(shè)計(jì)的初衷。RPC是面向活動(dòng)或方法的,無論這一方法是一個(gè)對象的成員方法還是全局方法,我們習(xí)慣了通過客戶端傳遞參數(shù)給他們?nèi)缓螳@得返回值的模式,但到了面向資源的模式中,這樣的認(rèn)識便成了理解REST的障礙。對URI本身的“操作” 只存在兩種:referencing和dereferencing,前者引用一個(gè)URI來指代一個(gè)資源,后者表示了通過URI來取回實(shí)際對象的命令,而這一命令的執(zhí)行是通過HTTP請求完成的。現(xiàn)在我們再以現(xiàn)實(shí)生活中的人名來類比一下,在現(xiàn)實(shí)世界里,無論我們喊一個(gè)人的名字多少次,這個(gè)人本身不會(huì)改變,他與名字的關(guān)系也不會(huì)改變。所以在網(wǎng)絡(luò)中,無論我們引用一個(gè)URI多少次,其指向的邏輯對象也不應(yīng)該改變。查詢字符串是URI的一部分,包含查詢字符串的URI也具有相同的性質(zhì)。舉例來說,http://www.google.com/search?q=REST&start=40永遠(yuǎn)都表示著“Google中搜索REST結(jié)果從第40條開始的若干記錄”這一對象,無論引用多少次這一邏輯對象本身都不會(huì)改變。這便是URI的冪等性,而這一性質(zhì)意味著包含查詢字符串的URI的確可以理解為某種方法調(diào)用,但是此類方法調(diào)用必須在邏輯上不改變URI所指向的對象。比如這樣的 URI:http://www.restsample.com/add?title=RESTWIKI,這個(gè)URI假設(shè)它只被用于POST操作,而每一次對它引用返回的(如果有返回值)都是一個(gè)新建的資源,而其本身不指向任何資源。在RPC中對查詢字符串諸如此類對URI的應(yīng)用,都是由于僅將HTTP作為一個(gè)傳輸協(xié)議來使用造成的,作為傳輸協(xié)議的HTTP僅有request和response兩個(gè)操作,而為了用這兩個(gè)操作去模擬企業(yè)應(yīng)用中的CRUD,人們便想到了查詢字符串。但是在REST中,HTTP回到了其應(yīng)用層協(xié)議的地位,對資源的CRUD操作使用HTTP原語來完成,所以REST中的URI也只需擔(dān)當(dāng)它原本的角色,即資源標(biāo)識與查找。
那么我們回到本文開始時(shí)那位朋友的問題:是不是無論傳遞什么東西都靠URI參數(shù)來做,就一定是符合REST風(fēng)格的架構(gòu)?顯然不是,而且在REST中傳遞什么東西都靠URI參數(shù)本身就是一種錯(cuò)誤的做法,URI在REST中的作用只是標(biāo)識和發(fā)現(xiàn)資源,它被這樣設(shè)計(jì)的目的是為了滿足REST這組約束集合中的約束,是REST決定了URI的使用方式,僅僅依靠URI的使用方法去界定一個(gè)架構(gòu)風(fēng)格是否為REST是不妥的。
REST中的URI使得其指代對象是可緩存的,比如上面那個(gè)Google搜索的例子,由于其結(jié)果在短時(shí)間內(nèi)不會(huì)改變,所以該URI可以被當(dāng)作KEY緩存此對象。而如果URI隱含了改變對象的意思,那么這樣的緩存機(jī)制就必須通過其他方式實(shí)現(xiàn)。另外,從資源角度出發(fā)設(shè)計(jì)的URI往往會(huì)產(chǎn)生對SEO更友好的結(jié)果,URI可以被看作資源的一個(gè)最簡要描述,也可以在其中包含所優(yōu)化的關(guān)鍵字。
it知識庫:閑話REST(二)對資源標(biāo)識符的一點(diǎn)認(rèn)識,轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請第一時(shí)間聯(lián)系我們修改或刪除,多謝。