REST 風格的 Web 服務入門指南和 (重要)REST關鍵原則

提醒:想掌握並理解REST風格的Web服務,必需要熟悉HTTP協議,不能光知道GET/POST兩種方式.詳細請看:

http://my.oschina.net/zhaoqian/blog/90315

首先向看一下REST在JavaEE裏的規範JAX-RS.

JavaTM API for RESTful Web Services (JAX-RS) 1.1 標準
JAX-RS定義了部署Web服務的API，這些Web服務根據Representational State Transfer (REST)體系風格構建。
在整個Java EE產品中，要求全部Java EE Web容器支持使用JAX-RS技術的應用程序。
此規範描述了做爲Servlet對服務進行部署。必須可以使用相應的部署模型來部署基於JAX-RS的應用程序，這種部署模型使用了web.xml描述符的servlet-class元素，它的名稱是應用程序提供的JAX-RS ApplicationConfig抽象類的擴展類。
此規範定義了一套可選的容器管理的功能和資源，它們會在Java EE容器中使用，全部這樣的特性和資源必須可用。
JAX-RS規範參見 http://jcp.org/en/jsr/detail?id=311 

上述是JavaEE6規範裏的一些說明,那就是說,JAX-RS是徹底的REST風格.那麼REST風格的Web服務又是什麼呢?

1.REST入門

rest，即REST(Representational State Transfer表述性狀態轉移)是一種針對網絡應用的設計和開發方式，能夠下降開發的複雜性，提升系統的可伸縮性。

對於當今最多見的網絡應用來講，resource identifier是url，generic connector interface是HTTP，第4條準則就是咱們常說的url不變性。這些概念中的resouce最容易令人產生誤解。resouce所指的並非數據，而是數據+特定的表現形式（representation），這也是爲何REST的全名是Representational State Transfer的緣由。舉個例子來講，「本月賣得最好的10本書」和「你最喜歡的10本書」在數據上可能有重疊（有一本書即賣得好，你又喜歡），甚至徹底相同。可是它們的representation不一樣，所以是不一樣的resource。
REST之因此可以簡化開發，是由於其引入的架構約束，好比Rails 1.2中對REST的實現默認把controller中的方法限制在7個：index、show、new、edit、create、update和destroy，這實際上就是對CURD的實現。更進一步講，Rails（也是當今大部分網絡應用）使用HTTP做爲generic connector interface，HTTP則把對一個url的操做限制在了4個以內：GET、POST、PUT和DELETE。

REST之因此可以提升系統的可伸縮性，是由於它強制全部操做都是stateless的，這樣就沒有context的約束，若是要作分佈式、作集羣，就不須要考慮context的問題了。同時，它令系統能夠有效地使用pool。

REST對性能的另外一個提高來自其對client和server任務的分配：server只負責提供resource以及操做resource的服務，而client要根據resource中的data和representation本身作render。這就減小了服務器的開銷。

兩個問題: 

1.如何使用REST.
2.REST和MVC的關係.
第一個問題假設REST是咱們應該採用的架構，而後討論如何使用.
第二個問題則要說明REST和當前最廣泛應用的MVC是什麼關係，互補仍是取代?

第一個問題: 如何使用REST?

我感受， REST除了給咱們帶來了一個嶄新的架構之外，還有一個重要的貢獻是在開發系統過程當中的一種新的思惟方式：經過url來設計系統的結構.根據REST，每一個url都表明一個resource，而整個系統就是由這些resource組成的。所以，若是url是設計良好的，那麼系統的結構就也應該是設計良好的。

對於非高手級的開發人員來講，考慮一個系統如何架構老是一個很抽象的問題.

敏捷開發所提倡的Test Driven Development(測試驅動開發)，其好處之一（我以爲是最大的好處）就是能夠經過testcase(測試用例)直觀地設計系統的接口.好比在尚未建立一個class的時候就編寫一個testcase，雖然設置不能經過編譯，可是testcase中的方法調用能夠很好地從class使用者的角度反映出須要的接口，從而爲class的設計提供了直觀的表現.

這與在REST架構中經過url設計系統結構很是相似。雖然咱們連一個功能都沒有實現，可是咱們能夠先設計出咱們認爲合理的url，這些url甚至不能鏈接到任何page或action，可是它們直觀地告訴咱們：系統對用戶的訪問接口就應該是這樣。根據這些url，咱們能夠很方便地設計系統的結構。

讓我在這裏重申一遍：REST容許咱們經過url設計系統，就像Test Driven Development容許咱們使用testcase設計class接口同樣

OK，既然url有這樣的好處，那咱們就着重討論一下如何設計url。網絡應用一般都是有hierarchy的，像棵大樹。咱們一般但願url也能反映出資源的層次性。好比對於一個blog應用：/articles表示全部的文章，/articles/1表示id爲1的文章，這都比較直觀。遺憾的是，網絡應用的資源結構永遠不會如此簡單。所以人們經常會問這樣一個問題：RESTful的url能覆蓋全部的用戶請求嗎？好比，login如何RESTful？search如何RESTful？

從REST的概念上來看，全部能夠被抽象爲資源的東東均可以使用RESTful的url。所以對於上面的兩個問題，若是login和search能夠被抽象爲資源，那麼就可使用RESTful的url.search比較簡單，由於它會返回搜索結果，所以能夠被抽象爲資源，而且只實現index方法就能夠了（只須要顯示搜索結果，沒有create、destory之類的東西）。

然而這裏面也有一個問題：search的關鍵字如何傳給server？
index方法顯然應該使用HTTP GET，這會把關鍵字加到url後面，固然不符合REST的風格。
要解決這個問題，能夠把每次search看做一個資源，所以要建立create和index方法，create用來在用戶點擊「搜索」按鈕是經過HTTP POST把關鍵字傳給server，而後index則用來顯示搜索結果。
這樣一來，咱們還能夠記錄用戶的搜索歷史。使用一樣的方法，咱們也能夠對login應用REST，即每次login動做是一個資源。

如今，咱們來看複雜一些的東東。如何用url表達「category(種類)爲ruby(紅色)的article(文章)」？一開始可能想到的是/category/ruby/articles，這種想法很直觀。可是我以爲裏面的category是不須要的，咱們能夠直接把「/ruby」理解爲「category是ruby」，也就是說「ruby」出現的位置說明了它指的就是category。OK，/ruby/articles，單單從這個url上看，咱們能得到多少關於category的信息呢？顯然category隱藏在了url後面，這樣作到底好很差，應該是仁者見仁，智者見智了。對於如何表達category這樣的東西，我還沒想出很好的方式，你們有什麼好idea，能夠一塊兒討論。(TMD….表示這段理解了半天)
　　另外還有一種url形式，它對應到程序中的繼承關係。好比product是一個父類，book和computer是其子類。那麼全部產品的url應該是/products，全部書籍的url應該是/books，全部電腦的url應該是/computers。這一想法就比較直觀了，並且再次驗證了url能夠幫助咱們進行設計的論點。
　　讓我再說明一下個人想法：若是每一個用戶需求均可以抽象爲資源，那麼就能夠徹底使用REST。
由此看來，使用REST的關鍵是如何抽象資源，抽象得越精確，對REST的應用就越好。所以，如何改變咱們目前根深蒂固的基於action的思想是最重要的.(我木有action思想,個人思想是事件—通知思想.感受發展的總趨勢就是原始的請求,響應,就是action.到JSF那樣的事件通知,但仍然屬於MVC,如今的rest就屬於URL類型的抽象模式.)
有了對第一個問題的討論，第二個問題就容易討論多了.

2.REST會取代MVC嗎？

仍是彼此是互補關係（就像AOP對於OOP）？答案是我以爲是互補.

若是咱們能夠把全部的用戶需求均可以抽象爲資源，那麼MVC就能夠退出歷史的舞臺了。若是狀況相反，那麼咱們就須要混合使用REST和MVC。
固然，這是很是理想的論斷。可能咱們沒法找到一種方法能夠把全部的用戶需求都抽象爲資源，由於保證這種抽象的完整性（即真的是全部需求均可以）須要形式化的證實。並且即便被證實出來了，因爲開發人員的能力和喜愛不一樣，MVC確定也會成爲很多人的首選。可是對於但願擁抱REST的人來講，這些都沒有關係。只要你開發的系統所設計的問題域能夠被合理地抽象爲資源，那麼REST就會成爲你的開發利器。

===================================================================================================

REST關鍵原則

大部分對REST的介紹是以其正式的定義和背景做爲開場的。但這兒且先按下不表，我先提出一個簡單扼要的定義：REST定義了應該如何正確地使用（這和大多數人的實際使用方式有很大不一樣）Web標準，例如HTTP和URI。若是你在設計應用程序時能堅持REST原則，那就預示着你將會獲得一個使用了優質Web架構（這將讓你受益）的系統。總之，五條關鍵原則列舉以下：

爲全部「事物」定義ID；
將全部事物連接在一塊兒；
使用標準方法；
資源多重表述；
無狀態通訊。

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

1. 爲全部「事物」定義ID

在這裏我使用了「事物」來代替更正式準確的術語「資源」，由於一條如此簡單的原則，不該該被淹沒在術語當中。思考一下人們構建的系統，一般會找到一系列值得被標識的關鍵抽象。每一個事物都應該是可標識的，都應該擁有一個明顯的ID——在Web中，表明ID的統一律念是：URI。URI構成了一個全局命名空間，使用URI標識你的關鍵資源意味着它們得到了一個惟1、全局的ID。
　　對事物使用一致的命名規則（naming scheme）最主要的好處就是你不須要提出本身的規則——而是依靠某個已被定義，在全球範圍中幾乎完美運行，而且能被絕大多數人所理解的規則。想一下你構建的上一個應用（假設它不是採用RESTful方式構建的）中的任意一個高級對象（high-level object），那就頗有可能看到許多從使用惟一標識中受益的用例。好比，若是你的應用中包含一個對顧客的抽象，那麼我能夠至關確定，用戶會但願將一個指向某個顧客的連接，能經過電子郵件發送到同事那裏，或者加入到瀏覽器的書籤中，甚至寫到紙上。更透徹地講：若是在一個相似於Amazon的在線商城中，沒有用惟一的ID（一個URI）標識它的每一件商品，可想而知這將是多麼可怕的業務決策。
　　當面對這個原則時，許多人驚訝於這是否意味着須要直接向外界暴露數據庫記錄（或者數據庫記錄ID）——自從多年以來面向對象的實踐告誡咱們，要將持久化的信息做爲實現細節隱藏起來以後，哪怕是剛有點想法都常會令人驚恐。可是這條原則與隱藏實現細節二者之間並無任何衝突：一般，值得被URI標識的事物——資源——要比數據庫記錄抽象的多。例如，一個定單資源能夠由定單項、地址以及許多其它方面（可能不但願做爲單獨標識的資源暴露出來）組成。標識全部值得標識的事物，領會這個觀念能夠進一步引導你創造出在傳統的應用程序設計中不常見的資源：一個流程或者流程步驟、一次銷售、一次談判、一份報價請求——這都是應該被標識的事物的示例。一樣，這也會致使建立比非RESTful設計更多的持久化實體。
　　下面是一些你可能想到的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 正如我選擇了建立便於閱讀的URI——這是個有用的觀點，儘管不是RESTful設計所必須的——應該能十分容易地推測出URI的含義：它們明顯地標識着單一「數據項」。可是再往下看：
　　http://example*com/orders/2007/11
　　http://example*com/products?color=green 首先，這兩個URI看起來與以前的稍有不一樣——畢竟，它們不是對一件事物的標識，而是對一類事物集合的標識（假定第一個URI標識了全部在2007年11月份提交的定單，第二個則是綠顏色產品的集合）。可是這些集合自身也是事物（資源），也應該被標識。
　　注意，使用惟1、全局統一的命名規則的好處，既適用於瀏覽器中的Web應用，也適用於機對機（machine-to-machine，m2m）通訊。
來對第一個原則作下總結：使用URI標識全部值得標識的事物，特別是應用中提供的全部「高級」資源，不管這些資源表明單一數據項、數據項集合、虛擬亦或實際的對象仍是計算結果等。

2.將全部事物連接在一塊兒

接下來要討論的原則有一個有點使人懼怕的正式描述：「超媒體被看成應用狀態引擎（Hypermedia as the engine of application state）」，有時簡寫爲HATEOAS。（嚴格地說，這不是我說的。）這個描述的核心是超媒體概念，換句話說：是連接的思想。連接是咱們在HTML中常見的概念，可是它的用處毫不侷限於此（用於人們網絡瀏覽）。
　　應用程序（已經檢索過文檔）如何「跟隨」連接檢索更多的信息。固然，若是使用一個遵照專用命名規範的簡單「id」屬性做爲連接，也是可行的——可是僅限於應用環境以內。使用URI表示連接的優雅之處在於，連接能夠指向由不一樣應用、不一樣服務器甚至位於另外一個大陸上的不一樣公司提供的資源——由於URI命名規範是全球標準，構成Web的全部資源均可以互聯互通。
　　超媒體原則還有一個更重要的方面——應用「狀態」。簡而言之，實際上服務器端（若是你願意，也能夠叫服務提供者）爲客戶端（服務消費者）提供一組連接，使客戶端能經過連接將應用從一個狀態改變爲另外一個狀態。稍後咱們會在另外一篇文章中探究這個方面的影響；目前，只須要記住：連接是構成動態應用的很是有效的方式。
　　對此原則總結以下：任何可能的狀況下，使用連接指引能夠被標識的事物（資源）。也正是超連接造就瞭如今的Web。

3.使用標準方法

　　在前兩個原則的討論中暗含着一個假設：接收URI的應用程序能夠經過URI明確地作一些有意義的事情。若是你在公共汽車上看到一個URI，你能夠將它輸入瀏覽器的地址欄中並回車——可是你的瀏覽器如何知道須要對這個URI作些什麼呢？
　　它知道如何去處理URI的緣由在於全部的資源都支持一樣的接口，一套一樣的方法（只要你樂意，也能夠稱爲操做）集合。在HTTP中這被叫作動詞（verb），除了兩個你們熟知的（GET和POST）以外，標準方法集合中還包含PUT、DELETE、HEAD和OPTIONS。這些方法的含義連同行爲許諾都一塊兒定義在HTTP規範之中。若是你是一名OO開發人員，就能夠想象到RESTful HTTP方案中的全部資源都繼承自相似於這樣的一個類（採用類Java、C#的僞語法描述，請注意關鍵的方法）：
　　class Resource {
　　Resource(URI u);
　　Response get();
　　Response post(Request r);
　　Response put(Request r);
　　Response delete();
　　} 因爲全部資源使用了一樣的接口，你能夠依此使用GET方法檢索一個表述（representation）——也就是對資源的描述。由於規範中定義了GET的語義，因此能夠確定當你調用它的時候不須要對後果負責——這就是爲何能夠「安全」地調用此方法。GET方法支持很是高效、成熟的緩存，因此在不少狀況下，你甚至不須要向服務器發送請求。還能夠確定的是，GET方法具備冪等性[譯註：指多個相同請求返回相同的結果]——若是你發送了一個GET請求沒有獲得結果，你可能不知道緣由是請求未能到達目的地，仍是響應在反饋的途中丟失了。冪等性保證了你能夠簡單地再發送一次請求解決問題。冪等性一樣適用於PUT（基本的含義是「更新資源數據，若是資源不存在的話，則根據此URI建立一個新的資源」）和DELETE（你徹底能夠一遍又一遍地操做它，直到得出結論——刪除不存在的東西沒有任何問題）方法。POST方法，一般表示「建立一個新資源」，也能被用於調用任意過程，於是它既不安全也不具備冪等性。
　　若是你採用RESTful的方式暴露應用功能（若是你樂意，也能夠稱爲服務功能），那這條原則和它的約束一樣也適用於你。若是你已經習慣於另外的設計方式，則很難去接受這條原則——畢竟，你極可能認爲你的應用包含了超出這些操做表達範圍的邏輯。請容許我花費一些時間來讓你相信不存在這樣的狀況。
　　來看下面這個簡單的採購方案例子：
　　能夠看到，例子中定義了兩個服務程序（沒有包含任何實現細節）。這些服務程序的接口都是爲了完成任務（正是咱們討論的OrderManagement和CustomerManagement服務）而定製的。若是客戶端程序試圖使用這些服務，那它必須針對這些特定接口進行編碼——不可能在這些接口定義以前，使用客戶程序去有目的地和接口協做。這些接口定義了服務程序的應用協議（application protocol）。
　　在RESTful HTTP方式中，你將經過組成HTTP應用協議的通用接口訪問服務程序。你可能會想出像這樣的方式：
　　能夠看到，服務程序中的特定操做被映射成爲標準的HTTP方法——爲了消除歧義，我建立了一組全新的資源。「這是騙人的把戲」，我聽見你叫嚷着。不，這不是欺騙。標識一個顧客的URI上的GET方法正好至關於getCustomerDetails操做。有人用三角形形象化地說明了這一點：
　　把三個頂點想象爲你能夠調節的按鈕。能夠看到在第一種方法中，你擁有許多操做，許多種類的數據以及固定數量的「實例」（本質上和你擁有的服務程序數量一致）。在第二種方法中，你擁有固定數量的操做，許多種類的數據和許多調用固定方法的對象。它的意義在於，證實了經過這兩種方式，你基本上能夠表示任何你喜歡的事情。
　　爲何使用標準方法如此重要？從根本上說，它使你的應用成爲Web的一部分——應用程序爲Web變成Internet上最成功的應用所作的貢獻，與它添加到Web中的資源數量成比例。採用RESTful方式，一個應用可能會向Web中添加數以百萬計的客戶URI；若是採用CORBA技術並維持應用的原有設計方式，那它的貢獻大抵只是一個「端點（endpoint）」——就比如一個很是小的門，僅僅容許有鑰匙的人進入其中的資源域。
　　統一接口也使得全部理解HTTP應用協議的組件能與你的應用交互。通用客戶程序（generic client）就是從中受益的組件的例子，例如curl、wget、代理、緩存、HTTP服務器、網關還有Google、Yahoo!、MSN等等。
　　總結以下：爲使客戶端程序能與你的資源相互協做，資源應該正確地實現默認的應用協議（HTTP），也就是使用標準的GET、PUT、POST和DELETE方法。

4.資源多重表述

　　到目前爲止咱們一直忽略了一個稍微複雜的問題：客戶程序如何知道該怎樣處理檢索到的數據，好比做爲GET或者POST請求的結果？緣由是，HTTP採起的方式是容許數據處理和操做調用之間關係分離的。換句話說，若是客戶程序知道如何處理一種特定的數據格式，那就能夠與全部提供這種表述格式的資源交互。讓咱們再用一個例子來闡明這個觀點。利用HTTP內容協商（content negotiation），客戶程序能夠請求一種特定格式的表述：
　　GET /customers/1234 HTTP/1.1
　　Host: example*com
　　Accept: application/vnd.mycompany.customer+xml 請求的結果多是一些由公司專有的XML格式表述的客戶信息。假設客戶程序發送另一個不一樣的請求，就以下面這樣：
　　GET /customers/1234 HTTP/1.1
　　Host: example*com
　　Accept: text/x-vcard 結果則多是VCard格式的客戶地址。（在這裏我沒有展現響應的內容，在其HTTP Content-type頭中應該包含着關於數據類型的元數據。）這說明爲何理想的狀況下，資源表述應該採用標準格式——若是客戶程序對HTTP應用協議和一組數據格式都有所「瞭解」，那麼它就能夠用一種有意義的方式與世界上任意一個RESTful HTTP應用交互。不幸的是，咱們不可能拿到全部東西的標準格式，可是，或許咱們能夠想到在公司或者一些合做夥伴中使用標準格式來營造一個小環境。固然以上狀況不只適用於從服務器端到客戶端的數據，反之既然——假若從客戶端傳來的數據符合應用協議，那麼服務器端就可使用特定的格式處理數據，而不去關心客戶端的類型。
　　在實踐中，資源多重表述還有着其它重要的好處：若是你爲你的資源提供HTML和XML兩種表述方式，那這些資源不只能夠被你的應用所用，還能夠被任意標準Web瀏覽器所用——也就是說，你的應用信息能夠被全部會使用Web的人獲取到。
　　資源多重表述還有另一種使用方式：你能夠將應用的Web UI歸入到Web API中——畢竟，API的設計一般是由UI能夠提供的功能驅動的，而UI也是經過API執行動做的。將這兩個任務合二爲一帶來了使人驚訝的好處，這使得使用者和調用程序都能獲得更好的Web接口。 總結：針對不一樣的需求提供資源多重表述。

5.無狀態通訊

　　無狀態通訊是我要講到的最後一個原則。首先，須要着重強調的是，雖然REST包含無狀態性（statelessness）的觀念，但這並非說暴露功能的應用不能有狀態——
　　事實上，在大部分狀況下這會致使整個作法沒有任何用處。REST要求狀態要麼被放入資源狀態中，要麼保存在客戶端上。或者換句話說，服務器端不能保持除了單次請求以外的，任何與其通訊的客戶端的通訊狀態。這樣作的最直接的理由就是可伸縮性—— 若是服務器須要保持客戶端狀態，那麼大量的客戶端交互會嚴重影響服務器的內存可用空間（footprint）。（注意，要作到無狀態通訊每每須要須要一些從新設計——不能簡單地將一些session狀態綁縛在URI上，而後就宣稱這個應用是RESTful。）
但除此之外，其它方面可能顯得更爲重要：無狀態約束使服務器的變化對客戶端是不可見的，由於在兩次連續的請求中，客戶端並不依賴於同一臺服務器。一個客戶端從某臺服務器上收到一份包含連接的文檔，當它要作一些處理時，這臺服務器宕掉了，多是硬盤壞掉而被拿去修理，多是軟件須要升級重啓——若是這個客戶端訪問了從這臺服務器接收的連接，它不會察覺到後臺的服務器已經改變了。

理論上的REST

　　我認可：以上我所說的REST不是真正的REST，並且我可能有點過多地熱衷於簡單化。但由於我想有一個不同凡響的開場，因此沒有在一開始就介紹其正式的定義和背景。如今就讓咱們稍微簡要地介紹一下這方面的內容。
　　首先，先前我並無明確地區分HTTP、RESTful HTTP和REST。要理解這些不一樣方面之間的關係，咱們要先來看看REST的歷史。
　　Roy T. Fielding在他的博士學位論文（實際上你應該訪問這個連接——至少對於一篇學術論文來講，它是至關易讀的。此論文已被翻譯成中文）中定義了術語REST。Roy曾是許多基本Web協議的主要設計者，其中包括HTTP和URIs，而且他在論文中對這些協議提出了不少想法。（這篇論文被譽爲「REST聖經」，這是恰當的——畢竟，是做者發明了這個術語，因此在定義上，他寫的任何內容都被認爲是權威的。）在論文中，Roy首先定義一種方法論來談論架構風格——高級、抽象的模式，來表達架構方法背後的核心理念。每個架構風格由一系列的約束（constraints）定義造成。架構風格的例子包括「沒有風格」（根本沒有任何約束）、管道和過濾器（pipe and filter）、客戶端/服務器、分佈式對象以及——你猜到它了——REST。
　　若是對你來講這些聽起來都太抽象了，那就對了——REST在本質上是一個能夠被許多不一樣技術實現的高層次的風格，並且能夠被實例化——經過爲它的抽象特性賦上不一樣的值。好比，REST中包含資源和統一接口的概念——也就是說，全部資源都應該對這些相同的方法做出反應。可是REST並無說明是哪些方法，或者有多少方法。
　　REST風格的一個「化身」即是HTTP（以及一套相關的一套標準，好比URI），或者稍微抽象一些：Web架構自身。接着上面的例子，HTTP使用HTTP動詞做爲REST統一接口的「實例」。因爲Fielding是在Web已經（或者至少是大部分）「完善」了以後才定義的REST風格，有人可能會爭論二者是否是100%的匹配。可是不管如何，總體上來講Web、HTTP和URI僅僅是REST風格的一個主要實現。不過，因爲Roy Fielding便是REST論文的做者，又對Web架構設計有過深遠的影響，二者類似也在情理之中。
　　最後，我在前面一次又一次地使用着術語「RESTful HTTP」，緣由很簡單：許多使用HTTP的應用由於一些理由並無遵循REST原則，有人會說使用HTTP而不遵循REST原則就等同於濫用HTTP。固然這聽起來有點狂熱——事實上違反REST約束的緣由一般是，僅僅由於每一個約束帶來的設計權衡可能不適合於一些特殊狀況。但一般，違背REST約束的緣由可歸咎於對其好處認知的缺少。來看一個明顯的反面案例：使用HTTP GET調用相似於刪除對象的操做，這違反了REST的安全約束和通常性常識（客戶程序不該爲此負責，服務器端開發人員大概不是有意而爲之）。但在隨後的文章中，我會說起更多這樣或那樣的對HTTP的濫用

總結

本文試圖對REST（Web架構）背後的概念提供快速的介紹。RESTful HTTP暴露功能的方式與RPC、分佈式對象以及Web Services是不相同的；要真正理解這些不一樣是須要一些心態的轉變。無論你構建的應用是僅僅想暴露Web UI仍是想把API變成Web的一份子，瞭解下REST的原則仍是有好處的。