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