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