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