gembin

深入淺出REST

REST關(guān)鍵原則

大部分對REST的介紹是以其正式的定義和背景作為開場的。但這兒且先按下不表，我先提出一個簡單扼要的定義：REST定義了應(yīng)該如何正確地使用 （這和大多數(shù)人的實際使用方式有很大不同）Web標準，例如HTTP和URI。如果你在設(shè)計應(yīng)用程序時能堅持REST原則，那就預(yù)示著你將會得到一個使用 了優(yōu)質(zhì)Web架構(gòu)（這將讓你受益）的系統(tǒng)?？傊?，五條關(guān)鍵原則列舉如下：

• 為所有“事物”定義ID
• 將所有事物鏈接在一起
• 使用標準方法
• 資源多重表述
• 無狀態(tài)通信

下面讓我們進一步審視這些原則。

為所有“事物”定義ID

在這里我使用了“事物”來代替更正式準確的術(shù)語“資源”，因為一條如此簡單的原則，不應(yīng)該被淹沒在術(shù)語當中。思考一下人們構(gòu)建的系統(tǒng)，通常會找到一 系列值得被標識的關(guān)鍵抽象。每個事物都應(yīng)該是可標識的，都應(yīng)該擁有一個明顯的ID——在Web中，代表ID的統(tǒng)一概念是：URI。URI構(gòu)成了一個全局命 名空間，使用URI標識你的關(guān)鍵資源意味著它們獲得了一個唯一、全局的ID。

對事物使用一致的命名規(guī)則（naming scheme）最主要的好處就是你不需要提出自己的規(guī)則——而是依靠某個已被定義，在全球范圍中幾乎完美運行，并且能被絕大多數(shù)人所理解的規(guī)則。想一下你 構(gòu)建的上一個應(yīng)用（假設(shè)它不是采用RESTful方式構(gòu)建的）中的任意一個高級對象（high-level object），那就很有可能看到許多從使用唯一標識中受益的用例。比如，如果你的應(yīng)用中包含一個對顧客的抽象，那么我可以相當肯定，用戶會希望將一個指 向某個顧客的鏈接，能通過電子郵件發(fā)送到同事那里，或者加入到瀏覽器的書簽中，甚至寫到紙上。更透徹地講：如果在一個類似于Amazon.com的在線商 城中，沒有用唯一的ID（一個URI）標識它的每一件商品，可想而知這將是多么可怕的業(yè)務(wù)決策。

當面對這個原則時，許多人驚訝于這是否意味著需要直接向外界暴露數(shù)據(jù)庫記錄（或者數(shù)據(jù)庫記錄ID）——自從多年以來面向?qū)ο蟮膶嵺`告誡我們，要將持 久化的信息作為實現(xiàn)細節(jié)隱藏起來之后，哪怕是剛有點想法都常會使人驚恐。但是這條原則與隱藏實現(xiàn)細節(jié)兩者之間并沒有任何沖突：通常，值得被URI標識的事 物——資源——要比數(shù)據(jù)庫記錄抽象的多。例如，一個定單資源可以由定單項、地址以及許多其它方面（可能不希望作為單獨標識的資源暴露出來）組成。標識所有 值得標識的事物，領(lǐng)會這個觀念可以進一步引導你創(chuàng)造出在傳統(tǒng)的應(yīng)用程序設(shè)計中不常見的資源：一個流程或者流程步驟、一次銷售、一次談判、一份報價請求—— 這都是應(yīng)該被標識的事物的示例。同樣，這也會導致創(chuàng)建比非RESTful設(shè)計更多的持久化實體。

下面是一些你可能想到的URI的例子：

http://example.com/customers/1234

http://example.com/orders/2007/10/776654

http://example.com/products/4554

http://example.com/processes/salary-increase-234 

正如我選擇了創(chuàng)建便于閱讀的URI——這是個有用的觀點，盡管不是RESTful設(shè)計所必須的——應(yīng)該能十分容易地推測出URI的含義：它們明顯地標識著單一“數(shù)據(jù)項”。但是再往下看：

http://example.com/orders/2007/11

http://example.com/products?color=green 

首先，這兩個URI看起來與之前的稍有不同——畢竟，它們不是對一件事物的標識，而是對一類事物集合的標識（假定第一個URI標識了所有在2007年11月份提交的定單，第二個則是綠顏色產(chǎn)品的集合）。但是這些集合自身也是事物（資源），也應(yīng)該被標識。

注意，使用唯一、全局統(tǒng)一的命名規(guī)則的好處，既適用于瀏覽器中的Web應(yīng)用，也適用于機對機（machine-to-machine，m2m）通信。

來對第一個原則做下總結(jié)：使用URI標識所有值得標識的事物，特別是應(yīng)用中提供的所有“高級”資源，無論這些資源代表單一數(shù)據(jù)項、數(shù)據(jù)項集合、虛擬亦或?qū)嶋H的對象還是計算結(jié)果等。

將所有事物鏈接在一起

接下來要討論的原則有一個有點令人害怕的正式描述：“超媒體被當作應(yīng)用狀態(tài)引擎（Hypermedia as the engine of application state）”，有時簡寫為HATEOAS。（嚴格地說，這不是我說的。）這個描述的核心是超媒體概念，換句話說：是鏈接的思想。鏈接是我們在HTML中常見的概念，但是它的用處絕不局限于此（用于人們網(wǎng)絡(luò)瀏覽）。考慮一下下面這個虛構(gòu)的XML片段：

 

23 

 

 

 

如果你觀察文檔中product和customer的鏈接，就可以很容易地想象到，應(yīng)用程序（已經(jīng)檢索過文檔）如何“跟隨”鏈接檢索更多的信息。當然，如果使用一個遵守專用命名規(guī)范的簡單“id”屬性作為鏈接，也是可行的——但是僅限于應(yīng)用環(huán)境之內(nèi)。使用URI表示鏈接的優(yōu)雅之處在于，鏈接可以指向由不同應(yīng)用、不同服務(wù)器甚至位于另一個大陸上的不同公司提供的資源——因為URI命名規(guī)范是全球標準，構(gòu)成Web的所有資源都可以互聯(lián)互通。

超媒體原則還有一個更重要的方面——應(yīng)用“狀態(tài)”。簡而言之，實際上服務(wù)器端（如果你愿意，也可以叫服務(wù)提供者）為客戶端（服務(wù)消費者）提供一組鏈 接，使客戶端能通過鏈接將應(yīng)用從一個狀態(tài)改變?yōu)榱硪粋€狀態(tài)。稍后我們會在另一篇文章中探究這個方面的影響；目前，只需要記住：鏈接是構(gòu)成動態(tài)應(yīng)用的非常有 效的方式。

對此原則總結(jié)如下：任何可能的情況下，使用鏈接指引可以被標識的事物（資源）。也正是超鏈接造就了現(xiàn)在的Web。

使用標準方法

在前兩個原則的討論中暗含著一個假設(shè)：接收URI的應(yīng)用程序可以通過URI明確地做一些有意義的事情。如果你在公共汽車上看到一個URI，你可以將它輸入瀏覽器的地址欄中并回車——但是你的瀏覽器如何知道需要對這個URI做些什么呢？

它知道如何去處理URI的原因在于所有的資源都支持同樣的接口，一套同樣的方法（只要你樂意，也可以稱為操作）集合。在HTTP中這被叫做動詞 （verb），除了兩個大家熟知的（GET和POST）之外，標準方法集合中還包含PUT、DELETE、HEAD和OPTIONS。這些方法的含義連同 行為許諾都一起定義在HTTP規(guī)范之中。如果你是一名OO開發(fā)人員，就可以想象到RESTful HTTP方案中的所有資源都繼承自類似于這樣的一個類（采用類Java、C#的偽語法描述，請注意關(guān)鍵的方法）：

class Resource {

Resource(URI u);

Response get();

Response post(Request r);

Response put(Request r);

Response delete();

} 

由于所有資源使用了同樣的接口，你可以依此使用GET方法檢索一個表述（representation）——也 就是對資源的描述。因為規(guī)范中定義了GET的語義，所以可以肯定當你調(diào)用它的時候不需要對后果負責——這就是為什么可以“安全”地調(diào)用此方法。GET方法 支持非常高效、成熟的緩存，所以在很多情況下，你甚至不需要向服務(wù)器發(fā)送請求。還可以肯定的是，GET方法具有冪等性[譯 注：指多個相同請求返回相同的結(jié)果]——如果你發(fā)送了一個GET請求沒有得到結(jié)果，你可能不知道原因是請求未能到達目的地，還是響應(yīng)在反饋的途中丟失了。 冪等性保證了你可以簡單地再發(fā)送一次請求解決問題。冪等性同樣適用于PUT（基本的含義是“更新資源數(shù)據(jù)，如果資源不存在的話，則根據(jù)此URI創(chuàng)建一個新 的資源”）和DELETE（你完全可以一遍又一遍地操作它，直到得出結(jié)論——刪除不存在的東西沒有任何問題）方法。POST方法，通常表示“創(chuàng)建一個新資 源”，也能被用于調(diào)用任意過程，因而它既不安全也不具有冪等性。

如果你采用RESTful的方式暴露應(yīng)用功能（如果你樂意，也可以稱為服務(wù)功能），那這條原則和它的約束同樣也適用于你。如果你已經(jīng)習慣于另外的設(shè)計方式，則很難去接受這條原則——畢竟，你很可能認為你的應(yīng)用包含了超出這些操作表達范圍的邏輯。請允許我花費一些時間來讓你相信不存在這樣的情況。

來看下面這個簡單的采購方案例子：

可以看到，例子中定義了兩個服務(wù)程序（沒有包含任何實現(xiàn)細節(jié)）。這些服務(wù)程序的接口都是為了完成任務(wù)（正是我們討論的 OrderManagement和CustomerManagement服務(wù)）而定制的。如果客戶端程序試圖使用這些服務(wù)，那它必須針對這些特定接口進行 編碼——不可能在這些接口定義之前，使用客戶程序去有目的地和接口協(xié)作。這些接口定義了服務(wù)程序的應(yīng)用協(xié)議（application protocol）。

在RESTful HTTP方式中，你將通過組成HTTP應(yīng)用協(xié)議的通用接口訪問服務(wù)程序。你可能會想出像這樣的方式：

可以看到，服務(wù)程序中的特定操作被映射成為標準的HTTP方法——為了消除歧義，我創(chuàng)建了一組全新的資源。“這是騙人的把戲”，我聽見你叫嚷著。 不，這不是欺騙。標識一個顧客的URI上的GET方法正好相當于getCustomerDetails操作。有人用三角形形象化地說明了這一點：

把三個頂點想象為你可以調(diào)節(jié)的按鈕。可以看到在第一種方法中，你擁有許多操作，許多種類的數(shù)據(jù)以及固定數(shù)量的“實例”（本質(zhì)上和你擁有的服務(wù)程序數(shù) 量一致）。在第二種方法中，你擁有固定數(shù)量的操作，許多種類的數(shù)據(jù)和許多調(diào)用固定方法的對象。它的意義在于，證明了通過這兩種方式，你基本上可以表示任何 你喜歡的事情。

為什么使用標準方法如此重要？從根本上說，它使你的應(yīng)用成為Web的一部分——應(yīng)用程序為Web變成Internet上最成功的應(yīng)用所做的貢獻，與 它添加到Web中的資源數(shù)量成比例。采用RESTful方式，一個應(yīng)用可能會向Web中添加數(shù)以百萬計的客戶URI；如果采用CORBA技術(shù)并維持應(yīng)用的 原有設(shè)計方式，那它的貢獻大抵只是一個“端點（endpoint）”——就好比一個非常小的門，僅僅允許有鑰匙的人進入其中的資源域。

統(tǒng)一接口也使得所有理解HTTP應(yīng)用協(xié)議的組件能與你的應(yīng)用交互。通用客戶程序（generic client）就是從中受益的組件的例子，例如curl、wget、代理、緩存、HTTP服務(wù)器、網(wǎng)關(guān)還有Google、Yahoo!、MSN等等。

總結(jié)如下：為使客戶端程序能與你的資源相互協(xié)作，資源應(yīng)該正確地實現(xiàn)默認的應(yīng)用協(xié)議（HTTP），也就是使用標準的GET、PUT、POST和DELETE方法。

資源多重表述

到目前為止我們一直忽略了一個稍微復(fù)雜的問題：客戶程序如何知道該怎樣處理檢索到的數(shù)據(jù)，比如作為GET或者POST請求的結(jié)果？原因是，HTTP 采取的方式是允許數(shù)據(jù)處理和操作調(diào)用之間關(guān)系分離的。換句話說，如果客戶程序知道如何處理一種特定的數(shù)據(jù)格式，那就可以與所有提供這種表述格式的資源交 互。讓我們再用一個例子來闡明這個觀點。利用HTTP內(nèi)容協(xié)商（content negotiation），客戶程序可以請求一種特定格式的表述：

GET /customers/1234 HTTP/1.1

Host: example.com 

Accept: application/vnd.mycompany.customer+xml  

請求的結(jié)果可能是一些由公司專有的XML格式表述的客戶信息。假設(shè)客戶程序發(fā)送另外一個不同的請求，就如下面這樣：

GET /customers/1234 HTTP/1.1

Host: example.com 

Accept: text/x-vcard 

結(jié)果則可能是VCard格式的客戶地址。（在這里我沒有展示響應(yīng)的內(nèi)容，在其HTTP Content-type頭中應(yīng)該包含著關(guān)于數(shù)據(jù)類型的元數(shù)據(jù)。）這說明為什么理想的情況下，資源表述應(yīng)該采用標準格式——如果客戶程序?qū)TTP應(yīng)用協(xié) 議和一組數(shù)據(jù)格式都有所“了解”，那么它就可以用一種有意義的方式與世界上任意一個RESTful HTTP應(yīng)用交互。 不幸的是，我們不可能拿到所有東西的標準格式，但是，或許我們可以想到在公司或者一些合作伙伴中使用標準格式來營造一個小環(huán)境。當然以上情況不僅適用于從 服務(wù)器端到客戶端的數(shù)據(jù)，反之既然——倘若從客戶端傳來的數(shù)據(jù)符合應(yīng)用協(xié)議，那么服務(wù)器端就可以使用特定的格式處理數(shù)據(jù)，而不去關(guān)心客戶端的類型。

在實踐中，資源多重表述還有著其它重要的好處：如果你為你的資源提供HTML和XML兩種表述方式，那這些資源不僅可以被你的應(yīng)用所用，還可以被任意標準Web瀏覽器所用——也就是說，你的應(yīng)用信息可以被所有會使用Web的人獲取到。

資源多重表述還有另外一種使用方式：你可以將應(yīng)用的Web UI納入到Web API中——畢竟，API的設(shè)計通常是由UI可以提供的功能驅(qū)動的，而UI也是通過API執(zhí)行動作的。將這兩個任務(wù)合二為一帶來了令人驚訝的好處，這使得 使用者和調(diào)用程序都能得到更好的Web接口。

總結(jié)：針對不同的需求提供資源多重表述。

無狀態(tài)通信

無狀態(tài)通信是我要講到的最后一個原則。首先，需要著重強調(diào)的是，雖然REST包含無狀態(tài)性（statelessness）的觀念，但這并不是說暴露功能的應(yīng)用不能有狀態(tài)——
事 實上，在大部分情況下這會導致整個做法沒有任何用處。REST要求狀態(tài)要么被放入資源狀態(tài)中，要么保存在客戶端上。或者換句話說，服務(wù)器端不能保持除了單 次請求之外的，任何與其通信的客戶端的通信狀態(tài)。這樣做的最直接的理由就是可伸縮性—— 如果服務(wù)器需要保持客戶端狀態(tài)，那么大量的客戶端交互會嚴重影響服務(wù)器的內(nèi)存可用空間（footprint）。（注意，要做到無狀態(tài)通信往往需要需要一些 重新設(shè)計——不能簡單地將一些session狀態(tài)綁縛在URI上，然后就宣稱這個應(yīng)用是RESTful。）

但除此以外，其它方面可能顯得更為重要：無狀態(tài)約束使服務(wù)器的變化對客戶端是不可見的，因為在兩次連續(xù)的請求中，客戶端并不依賴于同一臺服務(wù)器。一 個客戶端從某臺服務(wù)器上收到一份包含鏈接的文檔，當它要做一些處理時，這臺服務(wù)器宕掉了，可能是硬盤壞掉而被拿去修理，可能是軟件需要升級重啟——如果這 個客戶端訪問了從這臺服務(wù)器接收的鏈接，它不會察覺到后臺的服務(wù)器已經(jīng)改變了。

理論上的REST

我承認：以上我所說的REST不是真正的REST，而且我可能有點過多地熱衷于簡單化。但因為我想有一個與眾不同的開場，所以沒有在一開始就介紹其正式的定義和背景?，F(xiàn)在就讓我們稍微簡要地介紹一下這方面的內(nèi)容。

首先，先前我并沒有明確地區(qū)分HTTP、RESTful HTTP和REST。要理解這些不同方面之間的關(guān)系，我們要先來看看REST的歷史。

Roy T. Fielding在他的博士學位論文（實際上你應(yīng)該訪問這個鏈接——至少對于一篇學術(shù)論文來說，它是相當易讀的。此論文已被翻譯成中文） 中定義了術(shù)語REST。Roy曾是許多基本W(wǎng)eb協(xié)議的主要設(shè)計者，其中包括HTTP和URIs，并且他在論文中對這些協(xié)議提出了很多想法。（這篇論文被 譽為“REST圣經(jīng)”，這是恰當?shù)摹吘?，是作者發(fā)明了這個術(shù)語，所以在定義上，他寫的任何內(nèi)容都被認為是權(quán)威的。）在論文中，Roy首先定義一種方法 論來談?wù)?strong>架構(gòu)風格——高級、抽象的模式，來表達架構(gòu)方法背后的核心理念。每一個架構(gòu)風格由一系列的約束（constraints）定義形成。架構(gòu)風格的例子包括“沒有風格”（根本沒有任何約束）、管道和過濾器（pipe and filter）、客戶端/服務(wù)器、分布式對象以及——你猜到它了——REST。

如果對你來說這些聽起來都太抽象了，那就對了——REST在本質(zhì)上是一個可以被許多不同技術(shù)實現(xiàn)的高層次的風格，而且可以被實例化——通過為它的抽 象特性賦上不同的值。比如，REST中包含資源和統(tǒng)一接口的概念——也就是說，所有資源都應(yīng)該對這些相同的方法作出反應(yīng)。但是REST并沒有說明是哪些方 法，或者有多少方法。

REST風格的一個“化身”便是HTTP（以及一套相關(guān)的一套標準，比如URI），或者稍微抽象一些：Web架構(gòu)自身。接著上面的例子，HTTP使 用HTTP動詞作為REST統(tǒng)一接口的“實例”。由于Fielding是在Web已經(jīng)（或者至少是大部分）“完善”了之后才定義的REST風格，有人可能 會爭論兩者是不是100%的匹配。但是無論如何，整體上來說Web、HTTP和URI僅僅是REST風格的一個主要實現(xiàn)。不過，由于Roy Fielding即是REST論文的作者，又對Web架構(gòu)設(shè)計有過深遠的影響，兩者相似也在情理之中。

最后，我在前面一次又一次地使用著術(shù)語“RESTful HTTP”，原因很簡單：許多使用HTTP的應(yīng)用因為一些理由并沒有遵循REST原則，有人會說使用HTTP而不遵循REST原則就等同于濫用HTTP。 當然這聽起來有點狂熱——事實上違反REST約束的原因通常是，僅僅因為每個約束帶來的設(shè)計權(quán)衡可能不適合于一些特殊情況。但通常，違背REST約束的原 因可歸咎于對其好處認知的缺乏。來看一個明顯的反面案例：使用HTTP GET調(diào)用類似于刪除對象的操作，這違反了REST的安全約束和一般性常識（客戶程序不應(yīng)為此負責，服務(wù)器端開發(fā)人員大概不是有意而為之）。但在隨后的文 章中，我會提及更多這樣或那樣的對HTTP的濫用。

總結(jié)

本文試圖對REST（Web架構(gòu)）背后的概念提供快速的介紹。RESTful HTTP暴露功能的方式與RPC、分布式對象以及Web Services是不相同的；要真正理解這些不同是需要一些心態(tài)的轉(zhuǎn)變。不管你構(gòu)建的應(yīng)用是僅僅想暴露Web UI還是想把API變成Web的一份子，了解下REST的原則還是有好處的。

Stefan Tilkov是InfoQ SOA社區(qū)的首席編輯，并且是位于德國和瑞士的innoQ公司的共同創(chuàng)始人、首席顧問和REST狂熱分子首領(lǐng)。

posted on 2008-06-30 10:29 gembin 閱讀(669) 評論(0)  編輯  收藏 所屬分類: SOA