|
不知你是否意識(shí)到，圍繞著什么才是實(shí)現(xiàn)異構(gòu)的應(yīng)用到應(yīng)用通信的“正確”方式,，一場(chǎng)爭(zhēng)論正進(jìn)行的如火如荼：雖然當(dāng)前主流的方式明顯地集中在基于SOAP,、WSDL和WS-*規(guī)范的Web Services領(lǐng)域，但也有少數(shù)人用細(xì)小但洪亮的聲音主張說(shuō)更好的方式是REST,，表述性狀態(tài)轉(zhuǎn)移（REpresentational State Transfer）的簡(jiǎn)稱,。在本文中，我不會(huì)涉及爭(zhēng)論的話題,，而是嘗試對(duì)REST和RESTful HTTP應(yīng)用集成做實(shí)用性的介紹,。以我的經(jīng)驗(yàn)，有些話題一旦觸及就會(huì)引來(lái)眾多的討論,，當(dāng)涉及到這方面話題的時(shí)候,，我會(huì)深入詳細(xì)地闡述。 REST關(guān)鍵原則大部分對(duì)REST的介紹是以其正式的定義和背景作為開(kāi)場(chǎng)的,。但這兒且先按下不表,，我先提出一個(gè)簡(jiǎn)單扼要的定義：REST定義了應(yīng)該如何正確地使用（這和大多數(shù)人的實(shí)際使用方式有很大不同）Web標(biāo)準(zhǔn)，例如HTTP和URI,。如果你在設(shè)計(jì)應(yīng)用程序時(shí)能堅(jiān)持REST原則,，那就預(yù)示著你將會(huì)得到一個(gè)使用了優(yōu)質(zhì)Web架構(gòu)（這將讓你受益）的系統(tǒng)?？傊?，五條關(guān)鍵原則列舉如下：
下面讓我們進(jìn)一步審視這些原則。 為所有“事物”定義ID在這里我使用了“事物”來(lái)代替更正式準(zhǔn)確的術(shù)語(yǔ)“資源”,，因?yàn)橐粭l如此簡(jiǎn)單的原則,，不應(yīng)該被淹沒(méi)在術(shù)語(yǔ)當(dāng)中。思考一下人們構(gòu)建的系統(tǒng),，通常會(huì)找到一系列值得被標(biāo)識(shí)的關(guān)鍵抽象,。每個(gè)事物都應(yīng)該是可標(biāo)識(shí)的，都應(yīng)該擁有一個(gè)明顯的ID——在Web中,，代表ID的統(tǒng)一概念是：URI,。URI構(gòu)成了一個(gè)全局命名空間,，使用URI標(biāo)識(shí)你的關(guān)鍵資源意味著它們獲得了一個(gè)唯一、全局的ID,。 對(duì)事物使用一致的命名規(guī)則（naming scheme）最主要的好處就是你不需要提出自己的規(guī)則——而是依靠某個(gè)已被定義,，在全球范圍中幾乎完美運(yùn)行，并且能被絕大多數(shù)人所理解的規(guī)則,。想一下你構(gòu)建的上一個(gè)應(yīng)用（假設(shè)它不是采用RESTful方式構(gòu)建的）中的任意一個(gè)高級(jí)對(duì)象（high-level object）,，那就很有可能看到許多從使用唯一標(biāo)識(shí)中受益的用例,。比如，如果你的應(yīng)用中包含一個(gè)對(duì)顧客的抽象,，那么我可以相當(dāng)肯定,，用戶會(huì)希望將一個(gè)指向某個(gè)顧客的鏈接，能通過(guò)電子郵件發(fā)送到同事那里,，或者加入到瀏覽器的書簽中,，甚至寫到紙上。更透徹地講：如果在一個(gè)類似于Amazon.com的在線商城中,，沒(méi)有用唯一的ID（一個(gè)URI）標(biāo)識(shí)它的每一件商品,，可想而知這將是多么可怕的業(yè)務(wù)決策。 當(dāng)面對(duì)這個(gè)原則時(shí),，許多人驚訝于這是否意味著需要直接向外界暴露數(shù)據(jù)庫(kù)記錄（或者數(shù)據(jù)庫(kù)記錄ID）——自從多年以來(lái)面向?qū)ο蟮膶?shí)踐告誡我們,，要將持久化的信息作為實(shí)現(xiàn)細(xì)節(jié)隱藏起來(lái)之后，哪怕是剛有點(diǎn)想法都常會(huì)使人驚恐,。但是這條原則與隱藏實(shí)現(xiàn)細(xì)節(jié)兩者之間并沒(méi)有任何沖突：通常,，值得被URI標(biāo)識(shí)的事物——資源——要比數(shù)據(jù)庫(kù)記錄抽象的多。例如,，一個(gè)定單資源可以由定單項(xiàng),、地址以及許多其它方面（可能不希望作為單獨(dú)標(biāo)識(shí)的資源暴露出來(lái)）組成。標(biāo)識(shí)所有值得標(biāo)識(shí)的事物,，領(lǐng)會(huì)這個(gè)觀念可以進(jìn)一步引導(dǎo)你創(chuàng)造出在傳統(tǒng)的應(yīng)用程序設(shè)計(jì)中不常見(jiàn)的資源：一個(gè)流程或者流程步驟,、一次銷售、一次談判,、一份報(bào)價(jià)請(qǐng)求——這都是應(yīng)該被標(biāo)識(shí)的事物的示例,。同樣,，這也會(huì)導(dǎo)致創(chuàng)建比非RESTful設(shè)計(jì)更多的持久化實(shí)體,。 下面是一些你可能想到的URI的例子： http:///customers/1234 http:///orders/2007/10/776654 http:///products/4554 http:///processes/salary-increase-234 正如我選擇了創(chuàng)建便于閱讀的URI——這是個(gè)有用的觀點(diǎn)，盡管不是RESTful設(shè)計(jì)所必須的——應(yīng)該能十分容易地推測(cè)出URI的含義：它們明顯地標(biāo)識(shí)著單一“數(shù)據(jù)項(xiàng)”,。但是再往下看： http:///orders/2007/11 http:///products?color=green 首先,，這兩個(gè)URI看起來(lái)與之前的稍有不同——畢竟，它們不是對(duì)一件事物的標(biāo)識(shí),，而是對(duì)一類事物集合的標(biāo)識(shí)（假定第一個(gè)URI標(biāo)識(shí)了所有在2007年11月份提交的定單,，第二個(gè)則是綠顏色產(chǎn)品的集合）。但是這些集合自身也是事物（資源）,，也應(yīng)該被標(biāo)識(shí),。 注意，使用唯一,、全局統(tǒng)一的命名規(guī)則的好處,，既適用于瀏覽器中的Web應(yīng)用，也適用于機(jī)對(duì)機(jī)（machine-to-machine，m2m）通信,。 來(lái)對(duì)第一個(gè)原則做下總結(jié)：使用URI標(biāo)識(shí)所有值得標(biāo)識(shí)的事物,，特別是應(yīng)用中提供的所有“高級(jí)”資源，無(wú)論這些資源代表單一數(shù)據(jù)項(xiàng),、數(shù)據(jù)項(xiàng)集合,、虛擬亦或?qū)嶋H的對(duì)象還是計(jì)算結(jié)果等。 將所有事物鏈接在一起接下來(lái)要討論的原則有一個(gè)有點(diǎn)令人害怕的正式描述：“超媒體被當(dāng)作應(yīng)用狀態(tài)引擎（Hypermedia as the engine of application state）”,，有時(shí)簡(jiǎn)寫為HATEOAS,。（嚴(yán)格地說(shuō)，這不是我說(shuō)的,。）這個(gè)描述的核心是超媒體概念,，換句話說(shuō)：是鏈接的思想。鏈接是我們?cè)贖TML中常見(jiàn)的概念,，但是它的用處絕不局限于此（用于人們網(wǎng)絡(luò)瀏覽）,。考慮一下下面這個(gè)虛構(gòu)的XML片段： <order self="http:///customers/1234"> <amount>23</amount> <product ref="http:///products/4554"> <customer ref="http:///customers/1234"> </customer> </product></order> 如果你觀察文檔中product和customer的鏈接,，就可以很容易地想象到,，應(yīng)用程序（已經(jīng)檢索過(guò)文檔）如何“跟隨”鏈接檢索更多的信息。當(dāng)然,，如果使用一個(gè)遵守專用命名規(guī)范的簡(jiǎn)單“id”屬性作為鏈接,，也是可行的——但是僅限于應(yīng)用環(huán)境之內(nèi)。使用URI表示鏈接的優(yōu)雅之處在于,，鏈接可以指向由不同應(yīng)用,、不同服務(wù)器甚至位于另一個(gè)大陸上的不同公司提供的資源——因?yàn)閁RI命名規(guī)范是全球標(biāo)準(zhǔn),，構(gòu)成Web的所有資源都可以互聯(lián)互通。 超媒體原則還有一個(gè)更重要的方面——應(yīng)用“狀態(tài)”,。簡(jiǎn)而言之,，實(shí)際上服務(wù)器端（如果你愿意,，也可以叫服務(wù)提供者）為客戶端（服務(wù)消費(fèi)者）提供一組鏈接,，使客戶端能通過(guò)鏈接將應(yīng)用從一個(gè)狀態(tài)改變?yōu)榱硪粋€(gè)狀態(tài)。稍后我們會(huì)在另一篇文章中探究這個(gè)方面的影響,；目前,，只需要記住：鏈接是構(gòu)成動(dòng)態(tài)應(yīng)用的非常有效的方式,。 對(duì)此原則總結(jié)如下：任何可能的情況下,，使用鏈接指引可以被標(biāo)識(shí)的事物（資源）,。也正是超鏈接造就了現(xiàn)在的Web。 使用標(biāo)準(zhǔn)方法在前兩個(gè)原則的討論中暗含著一個(gè)假設(shè)：接收URI的應(yīng)用程序可以通過(guò)URI明確地做一些有意義的事情,。如果你在公共汽車上看到一個(gè)URI,，你可以將它輸入瀏覽器的地址欄中并回車——但是你的瀏覽器如何知道需要對(duì)這個(gè)URI做些什么呢？ 它知道如何去處理URI的原因在于所有的資源都支持同樣的接口,，一套同樣的方法（只要你樂(lè)意,，也可以稱為操作）集合。在HTTP中這被叫做動(dòng)詞（verb）,，除了兩個(gè)大家熟知的（GET和POST）之外,，標(biāo)準(zhǔn)方法集合中還包含PUT、DELETE,、HEAD和OPTIONS,。這些方法的含義連同行為許諾都一起定義在HTTP規(guī)范之中。如果你是一名OO開(kāi)發(fā)人員,，就可以想象到RESTful HTTP方案中的所有資源都繼承自類似于這樣的一個(gè)類（采用類Java,、C#的偽語(yǔ)法描述，請(qǐng)注意關(guān)鍵的方法）： class Resource {
Resource(URI u);
Response get();
Response post(Request r);
Response put(Request r);
Response delete();
}
由于所有資源使用了同樣的接口,，你可以依此使用GET方法檢索一個(gè)表述（representation）——也就是對(duì)資源的描述,。因?yàn)橐?guī)范中定義了GET的語(yǔ)義，所以可以肯定當(dāng)你調(diào)用它的時(shí)候不需要對(duì)后果負(fù)責(zé)——這就是為什么可以“安全”地調(diào)用此方法,。GET方法支持非常高效,、成熟的緩存，所以在很多情況下,，你甚至不需要向服務(wù)器發(fā)送請(qǐng)求,。還可以肯定的是，GET方法具有冪等性[譯注：指多個(gè)相同請(qǐng)求返回相同的結(jié)果]——如果你發(fā)送了一個(gè)GET請(qǐng)求沒(méi)有得到結(jié)果,，你可能不知道原因是請(qǐng)求未能到達(dá)目的地,，還是響應(yīng)在反饋的途中丟失了。冪等性保證了你可以簡(jiǎn)單地再發(fā)送一次請(qǐng)求解決問(wèn)題,。冪等性同樣適用于PUT（基本的含義是“更新資源數(shù)據(jù),，如果資源不存在的話，則根據(jù)此URI創(chuàng)建一個(gè)新的資源”）和DELETE（你完全可以一遍又一遍地操作它,，直到得出結(jié)論——?jiǎng)h除不存在的東西沒(méi)有任何問(wèn)題）方法。POST方法,，通常表示“創(chuàng)建一個(gè)新資源”,，也能被用于調(diào)用任意過(guò)程，因而它既不安全也不具有冪等性,。 如果你采用RESTful的方式暴露應(yīng)用功能（如果你樂(lè)意,，也可以稱為服務(wù)功能）,，那這條原則和它的約束同樣也適用于你。如果你已經(jīng)習(xí)慣于另外的設(shè)計(jì)方式,，則很難去接受這條原則——畢竟,，你很可能認(rèn)為你的應(yīng)用包含了超出這些操作表達(dá)范圍的邏輯。請(qǐng)?jiān)试S我花費(fèi)一些時(shí)間來(lái)讓你相信不存在這樣的情況,。 來(lái)看下面這個(gè)簡(jiǎn)單的采購(gòu)方案例子： 可以看到，例子中定義了兩個(gè)服務(wù)程序（沒(méi)有包含任何實(shí)現(xiàn)細(xì)節(jié)）,。這些服務(wù)程序的接口都是為了完成任務(wù)（正是我們討論的OrderManagement和CustomerManagement服務(wù)）而定制的,。如果客戶端程序試圖使用這些服務(wù)，那它必須針對(duì)這些特定接口進(jìn)行編碼——不可能在這些接口定義之前,，使用客戶程序去有目的地和接口協(xié)作,。這些接口定義了服務(wù)程序的應(yīng)用協(xié)議（application protocol）。 在RESTful HTTP方式中,，你將通過(guò)組成HTTP應(yīng)用協(xié)議的通用接口訪問(wèn)服務(wù)程序。你可能會(huì)想出像這樣的方式： 可以看到,，服務(wù)程序中的特定操作被映射成為標(biāo)準(zhǔn)的HTTP方法——為了消除歧義,，我創(chuàng)建了一組全新的資源。“這是騙人的把戲”,，我聽(tīng)見(jiàn)你叫嚷著,。不，這不是欺騙,。標(biāo)識(shí)一個(gè)顧客的URI上的GET方法正好相當(dāng)于getCustomerDetails操作,。有人用三角形形象化地說(shuō)明了這一點(diǎn)： 把三個(gè)頂點(diǎn)想象為你可以調(diào)節(jié)的按鈕,。可以看到在第一種方法中,，你擁有許多操作,，許多種類的數(shù)據(jù)以及固定數(shù)量的“實(shí)例”（本質(zhì)上和你擁有的服務(wù)程序數(shù)量一致）。在第二種方法中,，你擁有固定數(shù)量的操作,，許多種類的數(shù)據(jù)和許多調(diào)用固定方法的對(duì)象。它的意義在于,，證明了通過(guò)這兩種方式,，你基本上可以表示任何你喜歡的事情。 為什么使用標(biāo)準(zhǔn)方法如此重要,？從根本上說(shuō),，它使你的應(yīng)用成為Web的一部分——應(yīng)用程序?yàn)閃eb變成Internet上最成功的應(yīng)用所做的貢獻(xiàn),，與它添加到Web中的資源數(shù)量成比例。采用RESTful方式,，一個(gè)應(yīng)用可能會(huì)向Web中添加數(shù)以百萬(wàn)計(jì)的客戶URI,；如果采用CORBA技術(shù)并維持應(yīng)用的原有設(shè)計(jì)方式，那它的貢獻(xiàn)大抵只是一個(gè)“端點(diǎn)（endpoint）”——就好比一個(gè)非常小的門,，僅僅允許有鑰匙的人進(jìn)入其中的資源域,。 統(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)該正確地實(shí)現(xiàn)默認(rèn)的應(yīng)用協(xié)議（HTTP）,，也就是使用標(biāo)準(zhǔn)的GET、PUT,、POST和DELETE方法,。 資源多重表述到目前為止我們一直忽略了一個(gè)稍微復(fù)雜的問(wèn)題：客戶程序如何知道該怎樣處理檢索到的數(shù)據(jù)，比如作為GET或者POST請(qǐng)求的結(jié)果,？原因是,，HTTP采取的方式是允許數(shù)據(jù)處理和操作調(diào)用之間關(guān)系分離的。換句話說(shuō),，如果客戶程序知道如何處理一種特定的數(shù)據(jù)格式,，那就可以與所有提供這種表述格式的資源交互。讓我們?cè)儆靡粋€(gè)例子來(lái)闡明這個(gè)觀點(diǎn),。利用HTTP內(nèi)容協(xié)商（content negotiation）,，客戶程序可以請(qǐng)求一種特定格式的表述： GET /customers/1234 HTTP/1.1 Host: Accept: application/vnd.mycompany.customer+xml 請(qǐng)求的結(jié)果可能是一些由公司專有的XML格式表述的客戶信息。假設(shè)客戶程序發(fā)送另外一個(gè)不同的請(qǐng)求,，就如下面這樣： GET /customers/1234 HTTP/1.1 Host: Accept: text/x-vcard 結(jié)果則可能是VCard格式的客戶地址,。（在這里我沒(méi)有展示響應(yīng)的內(nèi)容，在其HTTP Content-type頭中應(yīng)該包含著關(guān)于數(shù)據(jù)類型的元數(shù)據(jù),。）這說(shuō)明為什么理想的情況下,，資源表述應(yīng)該采用標(biāo)準(zhǔn)格式——如果客戶程序?qū)TTP應(yīng)用協(xié)議和一組數(shù)據(jù)格式都有所“了解”，那么它就可以用一種有意義的方式與世界上任意一個(gè)RESTful HTTP應(yīng)用交互,。不幸的是,，我們不可能拿到所有東西的標(biāo)準(zhǔn)格式，但是,，或許我們可以想到在公司或者一些合作伙伴中使用標(biāo)準(zhǔn)格式來(lái)營(yíng)造一個(gè)小環(huán)境,。當(dāng)然以上情況不僅適用于從服務(wù)器端到客戶端的數(shù)據(jù)，反之既然——倘若從客戶端傳來(lái)的數(shù)據(jù)符合應(yīng)用協(xié)議,，那么服務(wù)器端就可以使用特定的格式處理數(shù)據(jù),，而不去關(guān)心客戶端的類型。 在實(shí)踐中,，資源多重表述還有著其它重要的好處：如果你為你的資源提供HTML和XML兩種表述方式,，那這些資源不僅可以被你的應(yīng)用所用，還可以被任意標(biāo)準(zhǔn)Web瀏覽器所用——也就是說(shuō),，你的應(yīng)用信息可以被所有會(huì)使用Web的人獲取到,。 資源多重表述還有另外一種使用方式：你可以將應(yīng)用的Web UI納入到Web API中——畢竟，API的設(shè)計(jì)通常是由UI可以提供的功能驅(qū)動(dòng)的,，而UI也是通過(guò)API執(zhí)行動(dòng)作的,。將這兩個(gè)任務(wù)合二為一帶來(lái)了令人驚訝的好處，這使得使用者和調(diào)用程序都能得到更好的Web接口,。 總結(jié)：針對(duì)不同的需求提供資源多重表述,。 無(wú)狀態(tài)通信無(wú)狀態(tài)通信是我要講到的最后一個(gè)原則。首先,，需要著重強(qiáng)調(diào)的是,，雖然REST包含無(wú)狀態(tài)性（statelessness）的觀念，但這并不是說(shuō)暴露功能的應(yīng)用不能有狀態(tài)—— 但除此以外,，其它方面可能顯得更為重要：無(wú)狀態(tài)約束使服務(wù)器的變化對(duì)客戶端是不可見(jiàn)的，因?yàn)樵趦纱芜B續(xù)的請(qǐng)求中,，客戶端并不依賴于同一臺(tái)服務(wù)器,。一個(gè)客戶端從某臺(tái)服務(wù)器上收到一份包含鏈接的文檔,，當(dāng)它要做一些處理時(shí)，這臺(tái)服務(wù)器宕掉了,，可能是硬盤壞掉而被拿去修理,，可能是軟件需要升級(jí)重啟——如果這個(gè)客戶端訪問(wèn)了從這臺(tái)服務(wù)器接收的鏈接，它不會(huì)察覺(jué)到后臺(tái)的服務(wù)器已經(jīng)改變了,。 理論上的REST我承認(rèn)：以上我所說(shuō)的REST不是真正的REST,，而且我可能有點(diǎn)過(guò)多地?zé)嶂杂诤?jiǎn)單化。但因?yàn)槲蚁胗幸粋€(gè)與眾不同的開(kāi)場(chǎng),，所以沒(méi)有在一開(kāi)始就介紹其正式的定義和背景?，F(xiàn)在就讓我們稍微簡(jiǎn)要地介紹一下這方面的內(nèi)容。 首先,，先前我并沒(méi)有明確地區(qū)分HTTP,、RESTful HTTP和REST。要理解這些不同方面之間的關(guān)系,，我們要先來(lái)看看REST的歷史,。 Roy T. Fielding在他的博士學(xué)位論文（實(shí)際上你應(yīng)該訪問(wèn)這個(gè)鏈接——至少對(duì)于一篇學(xué)術(shù)論文來(lái)說(shuō)，它是相當(dāng)易讀的,。此論文已被翻譯成中文）中定義了術(shù)語(yǔ)REST,。Roy曾是許多基本W(wǎng)eb協(xié)議的主要設(shè)計(jì)者，其中包括HTTP和URIs,，并且他在論文中對(duì)這些協(xié)議提出了很多想法,。（這篇論文被譽(yù)為“REST圣經(jīng)”，這是恰當(dāng)?shù)摹吘?，是作者發(fā)明了這個(gè)術(shù)語(yǔ),，所以在定義上，他寫的任何內(nèi)容都被認(rèn)為是權(quán)威的,。）在論文中,，Roy首先定義一種方法論來(lái)談?wù)?strong>架構(gòu)風(fēng)格——高級(jí)、抽象的模式,，來(lái)表達(dá)架構(gòu)方法背后的核心理念,。每一個(gè)架構(gòu)風(fēng)格由一系列的約束（constraints）定義形成。架構(gòu)風(fēng)格的例子包括“沒(méi)有風(fēng)格”（根本沒(méi)有任何約束）,、管道和過(guò)濾器（pipe and filter）,、客戶端/服務(wù)器、分布式對(duì)象以及——你猜到它了——REST,。 如果對(duì)你來(lái)說(shuō)這些聽(tīng)起來(lái)都太抽象了,，那就對(duì)了——REST在本質(zhì)上是一個(gè)可以被許多不同技術(shù)實(shí)現(xiàn)的高層次的風(fēng)格，而且可以被實(shí)例化——通過(guò)為它的抽象特性賦上不同的值。比如,，REST中包含資源和統(tǒng)一接口的概念——也就是說(shuō),，所有資源都應(yīng)該對(duì)這些相同的方法作出反應(yīng)。但是REST并沒(méi)有說(shuō)明是哪些方法,，或者有多少方法,。 REST風(fēng)格的一個(gè)“化身”便是HTTP（以及一套相關(guān)的一套標(biāo)準(zhǔn),，比如URI）,，或者稍微抽象一些：Web架構(gòu)自身。接著上面的例子,，HTTP使用HTTP動(dòng)詞作為REST統(tǒng)一接口的“實(shí)例”,。由于Fielding是在Web已經(jīng)（或者至少是大部分）“完善”了之后才定義的REST風(fēng)格，有人可能會(huì)爭(zhēng)論兩者是不是100%的匹配,。但是無(wú)論如何,，整體上來(lái)說(shuō)Web、HTTP和URI僅僅是REST風(fēng)格的一個(gè)主要實(shí)現(xiàn),。不過(guò),，由于Roy Fielding即是REST論文的作者，又對(duì)Web架構(gòu)設(shè)計(jì)有過(guò)深遠(yuǎn)的影響,，兩者相似也在情理之中,。 最后，我在前面一次又一次地使用著術(shù)語(yǔ)“RESTful HTTP”,，原因很簡(jiǎn)單：許多使用HTTP的應(yīng)用因?yàn)橐恍├碛刹](méi)有遵循REST原則,，有人會(huì)說(shuō)使用HTTP而不遵循REST原則就等同于濫用HTTP。當(dāng)然這聽(tīng)起來(lái)有點(diǎn)狂熱——事實(shí)上違反REST約束的原因通常是,，僅僅因?yàn)槊總€(gè)約束帶來(lái)的設(shè)計(jì)權(quán)衡可能不適合于一些特殊情況,。但通常，違背REST約束的原因可歸咎于對(duì)其好處認(rèn)知的缺乏,。來(lái)看一個(gè)明顯的反面案例：使用HTTP GET調(diào)用類似于刪除對(duì)象的操作,，這違反了REST的安全約束和一般性常識(shí)（客戶程序不應(yīng)為此負(fù)責(zé)，服務(wù)器端開(kāi)發(fā)人員大概不是有意而為之）,。但在隨后的文章中,，我會(huì)提及更多這樣或那樣的對(duì)HTTP的濫用。 總結(jié)本文試圖對(duì)REST（Web架構(gòu)）背后的概念提供快速的介紹,。RESTful HTTP暴露功能的方式與RPC,、分布式對(duì)象以及Web Services是不相同的；要真正理解這些不同是需要一些心態(tài)的轉(zhuǎn)變,。不管你構(gòu)建的應(yīng)用是僅僅想暴露Web UI還是想把API變成Web的一份子,，了解下REST的原則還是有好處的。 Stefan Tilkov是InfoQ SOA社區(qū)的首席編輯，并且是位于德國(guó)和瑞士的innoQ公司的共同創(chuàng)始人,、首席顧問(wèn)和REST狂熱分子首領(lǐng),。 查看英文原文：A Brief Introduction to REST |
|
|
