本文對RESTful HTTP的基礎原理做了一個概覽，探討了開發者在設計RESTful HTTP應用時所面臨的典型問題，展示了如何在實踐中應用REST架構風格，描述了常用的URI命名方法，討論了如何使用統一接口進行資源交互，何時使用PUT或POST以及如何支持非CURD操作等。
雖然REST受Web技術的影響很深，但是理論上REST架構風格并非綁定在HTTP上。然而，HTTP是唯一與REST相關的實例。基于該原因，本文描述了通過HTTP實現的REST，通常它也被稱為RESTful HTTP。REST是一種風格，而不是標準。因為既沒有REST RFC，也沒有REST協議規范或者類似的規定。REST架構是Roy Fielding（他也是HTTP和URI規范的主要作者之一）在一篇論文中描述的。像REST這樣的架構風格通常會定義一組高層決定讓應用程序去實現。所有實現了某種特定架構風格的應用程序，都使用相同的模式，也用相同的方式使用別的架構元素，如緩存，分布式策略等。Roy Fielding把REST定義成一種架構風格，其目標是“使延遲和網絡交互最小化，同時使組件實現的獨立性和擴展性最大化”
REST并沒有創造新的技術，組件或服務，隱藏在RESTful HTTP背后的理念是使用Web的現有特征和能力。RESTful HTTP定義了如何更好地使用現有Web標準中的一些準則和約束。
資源
資源是REST中最關鍵的抽象概念，它們是能夠被遠程訪問的應用程序對象。一個資源就是一個標識單位，任何可以被訪問或被遠程操縱的東西都可能是一個資源。資源可以是靜態的，也就是該資源的狀態永遠不會改變。相反，某些資源的狀態可能隨著時間推移呈現很大的可變性。這兩種類型的資源都是有效的。
圖1中所顯示的這些類都能被很容易地映射成資源。面向對象設計者不容易理解把實體類（如Hotel或者Room）映射成資源，同樣他們也不太理解從控制類（如coordination，事務和某個類的控制類）到資源的映射。
圖1：分析模型的例子
分析模型是識別資源的一個非常好的“切入點”。然而，并非只能進行1對1映射，比如， <Hotel>.listOccupancy()操作也可以被建模成資源。此外，也有可能某些資源只表示實體的某一部分。資源設計的主要驅動力是網絡因素而不是對象模型。
任何重要的資源都應該能夠通過一個唯一的標識被訪問。RESTful HTTP使用URI來識別資源。URI提供了Web通用的識別機制，它包含了客戶端直接與被引用的資源進行交互時需要的所有信息。
如何命名資源標識？
雖然RESTful HTTP并沒有明確指出如何構造一個URI路徑，但實際上經常被使用的是一些特定的命名模式。URI命名模式有助于應用程序調試和跟蹤，通常一個URI包含資源類型及其后面用于定位特定資源的標識。這樣的URI不包括指定業務操作的動詞（verb），而只用于定位資源。圖中a1給出了Hotel資源的一個示例，同一個Hotel資源也可以通過URI（a2）訪問。同一資源可以被多個URI引用。
(a1) http://localhost/hotel/656bcee2-28d2-404b-891b (a2) http://127.0.0.1/hotel/656bcee2-28d2-404b-891b (b) http://localhost/hotel/656bcee2-28d2-404b-891b/Room/4 (c) http://localhost/hotel/656bcee2-28d2-404b-891b/Reservation/15 (d) http://localhost/hotel/656bcee2-28d2-404b-891b/Room/4/Reservation/15 (e) http://localhost/hotel/656bcee2-28d2-404b-891b/Room/4/Reservation/15v7 (f) http://localhost/hotel/656bcee2-28d2-404b-891bv12
圖2：資源尋址的例子
URI也可以被資源用來在資源表示（representation）之間建立關聯。例如，Hotel表示通過URI去引用已分配的Room資源，而不是使用普通的RoomID。使用普通的ID會強制調用者通過對資源的訪問去構造URI，而調用者如果沒有主機名和基礎URI路徑等上下文信息是無法訪問到該資源的。
超鏈接常被客戶端用于資源導航。RESTful API是超文本驅動的，這表示客戶端通過獲得一個Hotel表示，就能夠導航到已分配的Room表示和Reservation表示。
在實踐中，圖1所示的這些類經常被映射成某種業務對象，這意味著在業務對象的整個生命周期中URI將保持不變。如果要創建一個新資源，則要為之分配一個新的URI。而一旦這個新資源被刪除，相應的URI則跟著失效。如圖2中的（a），（b），（c）和（d）就是這種標識的例子。另一方面，URI也可以用來引用資源快照，比如（e）和（f）就是對這類快照的引用，其URI中包含了一個版本標識。
URI還可以定位子資源，如示例中的（b），（c），（d）和（e）。通常，被聚集的對象會被映射成子資源，如Room是被Hotel聚集的。被聚集的對象通常沒有自己的生命周期，如果它的父對象被刪除，所有的被聚集對象也跟著被刪除。
然而，如果一個子資源可以從一個父資源移動到另一個父對象， 那么在它的URI中就不應該包含其父資源的標識。比如圖1中的Reservation資源，它就可以被分配給另一個Room資源。如果一個Reservation資源的URI包含了其父資源Room的標識，如（d）所示，則當Room實例標識改變時，如果該Reservation資源又被另一個資源引用的話，這就會出問題。為了避免無效的URI，Reservation應該通過（c）這樣的方式進行尋址。
通常，資源的URI是由服務器控制的。客戶端訪問資源時并不需要理解資源的URI命名空間結構。比如，使用（c）和（d）兩個URI結構對客戶端而言具有效果相同。
統一資源接口
為了簡化整體系統架構，REST架構風格包含了統一接口的概念。統一接口包含一組受限的良定義的操作，由它們進行資源的訪問和操作。不論什么資源，都使用相同的接口。客戶端與Hotel，Room或CreditScore等資源交互時使用的接口是一樣的。統一接口獨立于資源的URI，并且也不需要類似IDL的文件去描述可用的操作。
RESTful HTTP的接口非常流行且廣為使用。它包含標準的HTTP方法如GET，PUT和POST（瀏覽器使用它發出請求并提取頁面）。不幸的是，很多開發者認為實現RESTful應用就是用一種直接使用HTTP的方式，這種理解是錯誤的。舉個例子，HTTP方法的實現必須要遵循HTTP規范的，而通過GET方法創建或修改對象是不遵守HTTP規范的。
應用統一接口
關于何時以及如何使用不同的HTTP動詞（verb），在Fielding的論文中沒有任何表格、列表或其他方式的描述。對于大部分方法，如GET或 DELETE，通過閱讀HTTP規范就能清楚其含義，而對于POST和部分更新，就不那么容易了。在實踐中，對資源進行部分更新有好幾種方法，下文將有詳細介紹。
表1列出了大部分重要的方法GET，DELETE，PUT和POST的典型用法：
重要
方法 | 典型用法 | 典型狀態碼 | 安全？ | 冪等？ |
GET | - 獲取表示 - 變更時獲取表示（緩存） | 200（OK） - 表示已在響應中發出 204（無內容） - 資源有空表示 301（Moved Permanently） - 資源的URI已被更新 303（See Other） - 其他（如，負載均衡） 304（not modified）- 資源未更改（緩存） 400 （bad request）- 指代壞請求（如，參數錯誤） 404 （not found）- 資源不存在 406 （not acceptable）- 服務端不支持所需表示 500 （internal server error）- 通用錯誤響應 503 （Service Unavailable）- 服務端當前無法處理請求 | 是 | 是 |
DELETE | - 刪除資源 | 200 （OK）- 資源已被刪除 301 （Moved Permanently）- 資源的URI已更改
303 （See Other）- 其他，如負載均衡 400 （bad request）- 指代壞請求t
404 （not found）- 資源不存在
409 （conflict）- 通用沖突 500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務端當前無法處理請求 | 否 | 是 |
PUT | - 用客戶端管理的實例號創建一個資源 - 通過替換的方式更新資源 - 如果未被修改，則更新資源（樂觀鎖） | 200 （OK）- 如果已存在資源被更改
201 （created）- 如果新資源被創建 301（Moved Permanently）- 資源的URI已更改 303 （See Other）- 其他（如，負載均衡） 400 （bad request）- 指代壞請求 404 （not found）- 資源不存在 406 （not acceptable）- 服務端不支持所需表示/p> 409 （conflict）- 通用沖突 412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的沖突） 415 （unsupported media type）- 接受到的表示不受支持 500 （internal server error）- 通用錯誤響應 503 （Service Unavailable）- 服務當前無法處理請求 | 否 | 是 |
POST | - 使用服務端管理的（自動產生）的實例號創建資源 - 創建子資源 - 部分更新資源 - 如果沒有被修改，則不過更新資源（樂觀鎖） | 200（OK）- 如果現有資源已被更改
201（created）- 如果新資源被創建
202（accepted）- 已接受處理請求但尚未完成（異步處理） 301（Moved Permanently）- 資源的URI被更新
303（See Other）- 其他（如，負載均衡） 400（bad request）- 指代壞請求
404 （not found）- 資源不存在
406 （not acceptable）- 服務端不支持所需表示
409 （conflict）- 通用沖突
412 （Precondition Failed）- 前置條件失敗（如執行條件更新時的沖突）
415 （unsupported media type）- 接受到的表示不受支持 500 （internal server error）- 通用錯誤響應
503 （Service Unavailable）- 服務當前無法處理請求 | 否 | 否 |
表1：統一接口示例
表示
對資源的操縱永遠是通過其表示實現的。資源可能永遠不會在網絡中傳輸，相反，傳輸的是資源的表示。資源的表示包括數據和描述數據的元數據，例如，HTTP頭“Content-Type” 就是這樣一個元數據屬性。
圖3展示了如何使用Java獲取表示。該例程使用了Java HTTP庫xLightweb中的HttpClient類，這個庫由作者本人維護。
HttpClient httpClient = new HttpClient(); IHttpRequest request = new GetRequest(centralHotelURI); IHttpResponse response = httpClient.call(request);
圖3：獲取表示的Java例程
通過調用HTTP客戶端的call方法，一個訪問Hotel資源表示的HTTP請求就被發送出去。返回的表示如圖4所示，它也包含了用于指示實體主體的多媒體類型的Content-Type頭。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 277 Content-Type: application/x-www-form-urlencoded classification=Comfort&name=Central&RoomURI=http%3A%2F%2Flocalhost%2Fhotel%2F 656bcee2-28d2-404b-891b%2FRoom%2F2&RoomURI=http%3A%2F%2Flocalhost%2Fhotel%2F6 56bcee2-28d2-404b-891b%2FRoom%2F1
圖4：RESTful HTTP交互
如何支持特定表示？
為了避免傳輸很大的數據集，有時應該接收表示屬性一個子集。在實現時，用于指定部分屬性的一種方式就是支持對指定屬性的尋址，如圖5所示。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b/classification HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 26 Content-Type: application/x-www-form-urlencoded; charset=utf-8 classification=Comfort
圖5：屬性過濾
圖5中所示的GET調用只請求了一個屬性（classification），如果要請求多個屬性，所請求的屬性要用逗號隔開，如圖6所示。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b/classification,name HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 43 Content-Type: application/x-www-form-urlencoded; charset=utf-8 classification=Comfort&name=Central
圖6：多屬性過濾
確定所需屬性的另一種方法是使用查詢參數，通過它列出所請求的屬性，如圖7所示。查詢參數將用于定義查詢條件以及更復雜的過濾或查詢準則。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b?reqAttr=classification&reqAttr=name HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 43 Content-Type: application/x-www-form-urlencoded; charset=utf-8 classification=Comfort&name=Central
圖7：查詢字符串
在上述例子中，服務器總是返回以application/x-www-form-urlencoded編碼的媒體類型的表示。該媒體類型將實體編碼成鍵值對列表。鍵值方法理解起來很容易，但缺點是，它不適用與更加復雜的數據結構。此外，這種媒體類型不支持標量數據類型的綁定，如Integer，Boolean，Date等。基于這個原因，通常使用XML，JSON或Atom來表征資源（JSON也沒有定義Data類型的綁定）
HttpClient httpClient = new HttpClient(); IHttpRequest request = new GetRequest(centralHotelURI); request.setHeader("Accept", "application/json"); IHttpResponse response = httpClient.call(request); String jsonString = response.getBlockingBody().readString(); JSONObject jsonObject = (JSONObject) JSONSerializer.toJSON(jsonString); HotelHotel= (Hotel) JSONObject.toBean(jsonObject, Hotel.class);圖8：請求JSON表示
通過設置“Accept”請求頭，客戶端就可以請求指定的表示編碼。圖8展示了如何對application/json類型的表示的請求。JSONlib將把圖9中顯示的返回響應消息映射成Hotel bean。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/json RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 263 Content-Type: application/json; charset=utf-8 {"classification":"Comfort", "name":"Central", "RoomURI":["http://localhost/hotel/656bcee2-28d2-404b-891b/Room/1", "http://localhost/hotel/656bcee2-28d2-404b-891b/Room/2"]}圖9：JSON表示
如何報告錯誤？
當服務器不支持所請求的表示時怎么辦？圖10展示了一個請求XML表示資源的HTTP交互，若服務器不支持這種表示，它將返回一個HTTP 406響應，表示拒絕處理該請求。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: text/xml RESPONSE: HTTP/1.1 406 No match for accept header Server: xLightweb/2.6 Content-Length: 1468 Content-Type: text/html; charset=iso-8859-1 <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> <title>Error 406 No match for accept header</title> </head> <body> <h2>HTTP ERROR: 406</h2><pre>No match for accept header</pre> ... </body> </html>
圖10：不支持的表示
RESTful HTTP服務端程序必須根據HTTP規范返回狀態碼。狀態碼的第一個數字標識返回類型，1xx表示臨時響應，2xx表示成功響應 ，3xx代表轉發，4xx表示客戶端錯誤，5xx代表服務端錯誤。使用錯誤的響應碼，或者總返回200響應，并在消息主體中包含特定應用程序的響應，這兩種做法都是不好的實踐。
客戶代理和中介也要分析返回碼。例如，xLightweb HttpClient默認會把持久的HTTP連接保存在連接池中，當一個HTTP交互完成時，持久化HTTP連接就應返回到內部連接池已備重用。而只有完好的連接才能被放回連接池，比如，若返回碼是5xx，那該連接就不會重回連接池了。
有時某些特定的客戶端要求更簡潔的返回碼。一種方法是增加一個HTTP頭“X-Header”，用它來詳細描述HTTP狀態碼。
REQUEST: POST /Guest/ HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 94 Content-Type: application/x-www-form-urlencoded zip=30314&lastName=Gump&street=42+Plantation+Street&firstName=Forest&country=US& city=Baytown&state=LA RESPONSE: HTTP/1.1 400 Bad Request Server: xLightweb/2.6 Content-Length: 55 Content-Type: text/plain; charset=utf-8 X-Enhanced-Status: BAD_ADDR_ZIP AddressException: bad zip code 99566
圖11：附加狀態碼
通常只有在進行編程問題診斷時才需要詳細的錯誤碼。盡管比起詳細的錯誤碼，HTTP狀態碼的描述性總是要差很多，但是在大多數情況下，它們對于客戶端正確處理問題已經足夠了。另一種方法是在響應主體中包含詳細的錯誤碼。
PUT還是POST？
較之流行的RPC方式，HTTP方法不僅僅在方法名上有所不同，而且HTTP方法中的某些屬性（如冪等性，安全性等）也扮演著重要的角色。不同的HTTP方法的冪等性和安全性屬性也是不同的。
HttpClient httpClient = new HttpClient(); String[] params = new String[] { "firstName=Forest", "lastName=Gump", "street=42 Plantation Street", "zip=30314", "city=Baytown", "state=LA", "country=US"}; IHttpRequest request = new PutRequest(gumpURI, params); IHttpResponse response = httpClient.call(request);圖12：使用PUT方法
如圖12和13所示，使用PUT操作來創建一個新的Guest資源。PUT方法將封裝好的資源存放在Request-URI之下。該URI是由客戶端決定的，當Request-URI指向某現存資源時，該資源將被新資源替換。基于該原因，PUT方法一般用于創建新資源或更新現有資源。然而，通過使用PUT，資源的整個狀態都會被改變，若一個請求只需要修改zip域，它不得不包含該資源的其他域，如 firstName，city等。
REQUEST: PUT Hotel/guest/bc45-9aa3-3f22d HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 94 Content-Type: application/x-www-form-urlencoded zip=30314&lastName=Gump&street=42+Plantation+Street&firstName=Forest&country=US& city=Baytown&state=LA RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 36 Content-Type: text/plain; charset=utf-8 Location: http://localhost/guest/bc45-9aa3-3f22d The guest resource has been updated.
圖13：HTTP PUT交互
PUT方法是冪等的，冪等性意味著對于一個成功執行的請求，不管其執行多少次，其結果都是一致的。也就是說，只要你愿意，你可以用PUT方法對Hotel資源進行任意次更新，其結果都一樣。如果兩個PUT方法同時發生，那么只有其中之一會贏得最后的勝利并決定資源的最終狀態。刪除操作也是冪等的，如果一個PUT方法和DELETE方法同時發生，那么資源或者被更新，或者被刪除，而不可能停留在某個中間狀態。
如果你不確定是PUT還是DELETE被成功執行，并且沒有得到狀態碼409 (Conflict)或者 417 (Expectation Failed)的話，那么就重新執行一遍。而不需要附加的可靠性協議來避免重復請求，因為通常重復的請求不會有任何影響。
上述描述對于POST方法就不適用了，因為POST方法不是冪等的，若要兩次執行同一個POST請求那就要注意了。POST方法所缺失的冪等性就解釋了為什么當你每次重新發送POST請求時瀏覽器總是彈出警告。POST方法用于創建資源，而不需要由客戶端指定實例id，圖14展示了通過POST方法創建一個Hotel資源的HTTP交互過程。通常，客戶端使用只包含基路徑和資源類型名的URI來發送POST請求。
REQUEST: POST /HotelHTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 35 Content-Type: application/x-www-form-urlencoded; charset=utf-8 Accept: text/plain classification=Comfort&name=Central RESPONSE: HTTP/1.1 201 Created Server: xLightweb/2.6 Content-Length: 40 Content-Type: text/plain; charset=utf-8 Location: http://localhost/hotel/656bcee2-28d2-404b-891b the Hotelresource has been created
圖14：HTTP POST交互（創建）
POST方法也經常用于更新資源的部分內容，比如，如果我們要通過發送僅包含classification屬性的PUT請求去更新Hotel資源的話，這就是違反HTTP的，但是用POST方法則沒有問題。POST方法既不是冪等的，也不是安全的。圖15展示了一個執行部分更新的POST方法。
REQUEST: POST /hotel/0ae526f0-9c3d HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 19 Content-Type: application/x-www-form-urlencoded; charset=utf-8 Accept: text/plain classification=First+Class RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 52 Content-Type: text/plain; charset=utf-8 the Hotelresource has been updated (classification)
圖15： HTTP POST交互 （更新）
還可以使用PATCH方法來進行部分更新，PATCH方法是對資源進行部分更新的一個特殊方法。一個PATCH請求包含一個補丁文檔，它將應用于由Request-URI所指定的資源。然而PATCH的RFC規范還在草稿中。
使用HTTP緩存
為提高擴展性并降低服務端負載， RESTful的HTTP應用程序可以利用WEB基礎設施的緩存機制。HTTP已經意識到緩存是WEB基礎設施必不可少的一部分，比如，HTTP協議定義了專門的消息頭來支持緩存。如果服務端設置了這個頭，客戶端（如HTTP客戶端或Web緩存代理）就能夠有效地支持緩存策略。
HttpClient httpClient = new HttpClient(); httpClient.setCacheMaxSizeKB(500000); IHttpRequest request = new GetRequest(centralHotelURI + "/classification"); request.setHeader("Accept", "text/plain"); IHttpResponse response = httpClient.call(request); String classification = response.getBlockingBody.readString(); // ... sometime later re-execute the request response = httpClient.call(request); classification = response.getBlockingBody.readString();圖16：客戶端緩存交互
圖16顯示了一個重復的GET調用。通過設置最大緩存大小的值>0激活了HttpClient的緩存功能。如果響應消息中包含了刷新頭，比如Expires或Cache-Control: max-age，該響應就會被HttpClient緩存。這些頭指明了關聯的表示可以保鮮的時間為多久。如果在一段時間內發出了相同的請求，那么HttpClient就會使用緩存為這些請求提供服務，而不需要重復進行網絡調用。在網絡上總共只有一次HTTP交互，如圖17所示。諸如WEB代理之類的緩存中介也實現了相同的功能，而且該緩存還可以在不同客戶端之間共享。
REQUEST: GET /hotel/656bcee2-28d2-404b-891b/classification HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: text/plain RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Cache-Control: public, max-age=60 Content-Length: 26 Content-Type: text/plain; charset=utf-8 comfort
圖17：包含過期頭的HTTP響應
過期模型在靜態資源上很好用，可是，對于動態資源（資源狀態經常改變且無法預測）則不盡相同。HTTP通過驗證頭，如Last-Modified以及ETag來支持動態資源的緩存。與過期模型相比，驗證模型沒有節省網絡調用。但是，當執行帶條件的GET方法時它會對昂貴的操作節約網絡傳輸，圖 18（2.request）顯示了帶條件的GET操作，它帶有一個額外的Last-Modified頭，這個頭包含了緩存對象最后修改日期。如果該資源未被更改，服務端將會返回一個304 (Not Modified) 響應。
1. REQUEST: GET /hotel/656bcee2-28d2-404b-891b/Reservation/1 HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded 1. RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 252 Content-Type: application/x-www-form-urlencoded Last-Modified: Mon, 01 Jun 2009 08:56:18 GMT from=2009-06-01T09%3A49%3A09.718&to=2009-06-05T09%3A49%3A09.718&guestURI= http%3A%2F%2Flocalhost%2Fguest%2Fbc45-9aa3-3f22d&RoomURI=http%3A%2F%2F localhost%2Fhotel%2F656bcee2-28d2-404b-891b%2FRoom%2F1 2. REQUEST: GET /hotel/0ae526f0-9c3d/Reservation/1 HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded If-Modified-Since: Mon, 01 Jun 2009 08:56:18 GMT 2. RESPONSE: HTTP/1.1 304 Not Modified Server: xLightweb/2.6 Last-Modified: Mon, 01 Jun 2009 08:56:18 GMT
圖18：基于驗證的緩存
不要在服務端存儲應用狀態
RESTful HTTP的交互必須是無狀態的，這表明每一次請求要包含處理該請求所需的一切信息。客戶端負責維護應用狀態。RESTful服務端不需要在請求間保留應用狀態，服務端負責維護資源狀態而不是應用狀態。服務端和中介能夠理解獨立的請求和響應。Web緩存代理擁有一切正確處理請求所需的信息并管理它的緩存。
這種無狀態的方法是實現高擴展和高可用應用的基本原則。通常無狀態使得每一個客戶請求可以由不同的服務器來響應，當流量增加時，新的服務器可以加進來，而如果某個服務器失敗，它也可以從集群中移除。若要了解關于負載均衡以及故障恢復方面的更詳細信息，請參考這篇文章服務器負載均衡架構 。
對non-CRED操作的支持
開發者經常想了解如何將non-CRUD（Create-Read-Update-Delete）操作映射到資源。顯然，Create、Read、Update和Delete等操作能夠很容易地映射到資源的方法。然而， RESTful HTTP還不僅限于面向CRUD的應用。
圖19: RESTful HTTP資源
就如圖19所示的creditScoreCheck而言，它提供了一個non-CRUD操作creditScore(...)，該操作接受一個address，計算出score并返回。這樣的操作可以通過CreditScoreResource實現，該資源代表著計算的返回。圖20展示了一個GET方法，它傳入address，然后提取CreditScoreResource表示，查詢參數被用來指定CreditScoreResource。GET方法是安全的，并且可緩存，所提它很適用于CreditScore Check的creditScore(...)方法的非功能性行為。計算的結果可以緩存一段時間，如圖20所示，響應包含了一個緩存頭，它通知客戶端和中介執行響應緩存。
REQUEST: GET /CreditScore/?zip=30314&lastName=Gump&street=42+Plantation+Street& firstName=Forest&country=US&city=Baytown&state=LA HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Accept: application/x-www-form-urlencoded RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 31 Content-Type: application/x-www-form-urlencoded Cache-Control: public, no-transform, max-age=300 scorecard=Excellent&points=92
圖20：Non-CRUD HTTP GET交互
上述例子還顯示了GET方法的局限性。盡管HTTP規范并沒有指定URL的最大長度，但是實際上客戶端，中介以及服務端對URL的長度都有限制。基于此，通過GET的查詢參數發送一個很大的實體可能會因為中介和服務器對URL長度的限制而失敗。
另一解決方法是使用POST方法，如果作了設置，它也是可緩存的。如圖21所示，第一個POST請求的結果是創建了一個虛擬資源CreditScoreResource。輸入的address數據用text/card這個mime類型進行編碼，在服務端計算得到score之后，它發回一個201（created）響應，該響應包含著所創建的CreditScoreResource資源的URI。 示例中還展示了如果進行了設定，POST響應也可以被緩存。通過一個GET請求就能夠取到計算結果。GET響應也包含一個緩存控制頭，如果客戶端緊接著重新執行這兩次請求，那么它們都可由緩存進行響應。
1. REQUEST: POST /CreditScore/ HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 Content-Length: 198 Content-Type: text/x-vcard Accept: application/x-www-form-urlencoded BEGIN:VCARD VERSION:2.1 N:Gump;Forest;;;; FN:Forest Gump ADR;HOME:;;42 Plantation St.;Baytown;LA;30314;US LABEL;HOME;ENCODING=QUOTED-PRINTABLE:42 Plantation St.=0D=0A30314 Baytown=0D=0ALA US END:VCARD 1. RESPONSE: HTTP/1.1 201 Created Server: xLightweb/2.6 Cache-Control: public, no-transform, max-age=300 Content-Length: 40 Content-Type: text/plain; charset=utf-8 Location: http://localhost/CreditScore/l00000001-l0000005c the credit score resource has been created 2. REQUEST: GET /CreditScore/l00000001-l0000005c HTTP/1.1 Host: localhost User-Agent: xLightweb/2.6 2. RESPONSE: HTTP/1.1 200 OK Server: xLightweb/2.6 Content-Length: 31 Content-Type: application/x-www-form-urlencoded Cache-Control: public, no-transform, max-age=300 scorecard=Excellent&points=92
圖21： Non-CRUD HTTP POST交互
還有其他不同的實現方式。比如不返回201響應，而返回301(Moved Permanently)轉發響應。該響應缺省是可緩存的。其他避免二次請求的方法是在201響應中增加一個新創建的CreditScoreResource資源的表示。
總結
大多數SOA架構（如SOAP或CORBA）都試圖映射如圖1所示的類模型，或多或少是一對一的遠程訪問。通常，這些SOA架構的比較多地關注在編程語言對象的透明映射上，這種映射很容易理解，且易于跟蹤。可是，它們把對分布性和擴展性等方面的關注排在第二位。
相反，REST架構風格的最主要驅動是分布性和擴展性。RESTful HTTP接口的設計是由網絡因素而非編程語言的綁定驅動的。 RESTful HTTP也沒有試圖去封裝很那些難隱藏的因素，如網絡延遲，網絡健壯性以及網絡帶寬等。
RESTful HTTP應用用一種直接的方式使用HTTP協議，而不需任何抽象層，也不存在REST指定的數據域，如錯誤域，安全令牌域等。RESTful HTTP應用只使用WEB的固有能力。設計RESTful HTTP的接口意味著遠程結構的設計者必須在HTTP協議上進行思考。這通常增加了開發周期中額外步驟。
然而，RESTful HTTP使得應用程序實現具有高擴展性，更健壯。特別是為很大用戶群提供Web應用的公司，如 WebMailing或SocialNetworking的應用就能從REST架構風格中獲益。通常，這些應用要更快更高地擴展，而且，這些公司通常在一些低預算的基礎設施（基于廣泛使用的標準組件和軟件之上）上運行應用。
關于作者
Gregor Roth，xLightweb HTTP庫的作者。在United Internet組織擔任軟件架構師，該組織是最重要的歐洲因特網服務提供商，其產品有GMX, 1&1, and Web.de等。他感興趣的領域包括軟件和系統架構、企業架構管理、面向對象設計、分布式計算和開發方法論等。
參考文獻
Architectural Styles and the Design of Network-based Software Architectures
REST Eye for the SOA Guy
Presentation: Steve Vinoski on REST, Reuse and Serendipity
A Brief Introduction to REST
Fallacies of Distributed Computing
Server load balancing architectures
Asynchronous HTTP and Comet architectures
JSON-lib
xLightweb
查看英文原文：RESTful HTTP in practic。
-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;