Rest架構與案例

1、REST架構與案例分析恒生電子股份有限公司 | 回顧Web的發(fā)展 HTTP 主流Web服務介紹 REST抽象概念 REST式架構 - ROA REST案例分析 REST式服務框架- Restlet恒生電子股份有限公司 | HTTP(HypertextTransferProtocol) 超文本傳輸協(xié)議？NO，超文本轉移協(xié)議！ URI/URL Web1.0靜態(tài)(只讀)倉庫Web2.0雙向，交互 Web3.0 數(shù)據(jù)化，服務化，平臺化 HTMLJavaScript 富客戶端(Flex Silverlight) SOAP恒生電子股份有限公司 |客戶端服務器響應請求恒生電子股份有限公司 | 方法方法(me

2、thod):表示客戶端希望服務器如何處理該信封。有GET、POST、PUT、DELETE、HEAD、OPTION、TRACE和CONNECT八個方法。 路徑路徑(path):請求鏈接里主機名后面部分，即信封上的地址。 請求報頭請求報頭(requestheaders):一組起元數(shù)據(jù)作用的鍵值對，類似信封上貼的標簽信息。HTTP除定義了一套標準報頭外，程序也可以自己定義報頭。 實體主體實體主體(entity-body):也稱作文檔或表示，即信封里的文檔。一般情況下，請求實體主體可為空。恒生電子股份有限公司 | 響應代碼響應代碼(responsecode):通知客戶端請求成功或失敗，以及如何處理信封

3、里的內容。 響應報頭響應報頭(responseheader):類似請求報頭。 實體主體實體主體(entity-body):同樣是放在信封里的文檔，但絕大多數(shù)情況它不會為空。恒生電子股份有限公司 | 標準報頭標準報頭Host User-Agent Accept-Charset Accept-Encoding Accept-Language If-Modified-Since Content-Type Content-Length Content-Encoding Content-Language Accept-Ranges Expires Last-Modified Etag Data WWW-

4、Authenticate Date Cache-Control 非標準非標準報頭報頭Cookie Set-Cookie X-WSSE 自定義報頭自定義報頭不重新發(fā)明已存在的報頭不將應該放在實體主體里的信息放進報頭命名遵循慣例，名稱以“X-”開頭恒生電子股份有限公司 | 狀態(tài)碼(3位數(shù)字)分類 1xx:通知通知僅在與HTTP服務器溝通時使用 2xx:成功成功成功收到、理解和接受動作200(“OK”)、201(“Created”)、204(“No Content”) 3xx:重定向重定向為完成請求，必須進一步采取措施301(“Moved Permanently”)、303(“See Other”)

5、 4xx:客戶端錯誤客戶端錯誤請求包含錯誤的語法或不能完成400(“Bad Request”)、401(“Unauthorized”)、403(“Forbidden”) 404(“Not Found”)、405(“Method Not Allowed”) 5xx:服務器端錯誤服務器端錯誤服務器不能完成明顯合理的請求 500(“Internal Server Error”)、503(“Service Unavailable”) 恒生電子股份有限公司 |恒生電子股份有限公司 | REST式面向資源的架構具備Web特征的服務：靜態(tài)網(wǎng)站、許多未采用SOAP的只讀Web服務、許多只讀型Web應用等 PR

6、C式架構所有采用XML-RPC遺留協(xié)議的服務，幾乎所有的SOAP服務 REST-RPC混合架構大部分Web應用，大量采用MVC模式的Web應用恒生電子股份有限公司 | REST(Representational State Transfer) 表述性狀態(tài)轉移，一種架構風格 不是一個具體的標準或者架構，只是一套設計原則和一種架構風格 HTTP是這種架構風格的實現(xiàn) 一種真實描述Web的方式，不被特定時期的特定應用程序概念歪曲，是對Web的本質回歸 提供區(qū)分良好實踐和糟糕實踐的途徑：判斷特定實踐是否與Web架構一致恒生電子股份有限公司 | URI規(guī)范(RFC 2396)：“資源可以是任何有標示的東西

7、”“并非所有的資源都是通過網(wǎng)絡能夠獲取的” 任何事物，只要有被引用的必要，就是一個資源(resource)。它可以是一個實物，也可以是一個抽象的概念。 通常一個資源是某個可以存放在計算機上并體現(xiàn)為比特流的事物。在Web中，可以這樣認為資源是URI標示的東西。恒生電子股份有限公司 | 資源和表示不是一碼事。Web上獲取的不是資源，而是資源的表示。 對于給定的資源，可以有很多不同的表示。 資源表示表示HTML表示表示XML 表示表示Text Flash 表示表示標識符（URI）恒生電子股份有限公司 | 在客戶-服務端模式下，讓客戶端維護應用狀態(tài)，并確保服務端向服務器發(fā)出的請求都包含理解請求所需的全

8、部信息，而服務器不應該維護該狀態(tài)。 REST式解決方案是使用URI。每個概念上獨立的資源都可使用單個URI，不希望通過Cookie或隱藏在有效負載的參數(shù)來提供額外信息。例：查看john在某網(wǎng)站2008-10-10的所有文檔資料http:/ |恒生電子股份有限公司 | 網(wǎng)絡上的所有事物都被抽象為資源 每個資源對應一個唯一的資源標識URI 通過HTTP協(xié)議方法作連接器對資源進行操作 對資源的任何操作不改變資源標識URI 所有的服務器操作都是無狀態(tài)的恒生電子股份有限公司 | 服務端必須維持狀態(tài) 難以對URI進行緩存 應用部署難以水平擴展 存在安全隱患 數(shù)據(jù)與表象混雜 無法準確表達與理解請求含義 對不

9、同客戶端要分代碼處理 URI難以持久化 暴露技術實現(xiàn)且易變更URI 代碼方法入侵URI恒生電子股份有限公司 | 面向資源的架構(Resource-OrientedArchitecture，ROA) 一個具體的REST式架構 一種把實際問題轉換成REST式Web服務的方法恒生電子股份有限公司 | 資源 資源的名稱(URI) 資源的表示 資源間的鏈接恒生電子股份有限公司 | 某軟件的1.0.3版 一張杭州旅游地圖 QC中某個項目的Bug列表 某某公司04季度的營業(yè)額 一個風險點或一個風險模型 某張報表某個單元格的內容 一個流程中的一個節(jié)點任務 陳老師與女明星的關系 等等恒生電子股份有限公司 | U

10、RI既是資源的名稱，也是資源的地址。 一個資源必須至少有一個URI，而一個URI只能指示一個資源。 任何兩個資源不可能是同一個。 兩個不同的資源在某一時期可能指向同樣的數(shù)據(jù)。 同一資源具有多個URIs的雖然能讓引用變得更加容易，但壞處是將產(chǎn)生“稀釋效應”，客戶端無法自動驗證它們是指向同一個資源。恒生電子股份有限公司 | 對于一個本身就是一些數(shù)據(jù)項的資源，最容易想到的一個表示就是這些數(shù)據(jù)本身。 如HTML格式的網(wǎng)頁新聞 對于代表實物或其他難以歸結為信息的事物，其表示就是關于資源的狀態(tài)的任何有用信息。 如“連上Web的自動飲料機”提供關于實物飲料的數(shù)據(jù) 即使在一個對象的諸多表示中，已經(jīng)有一個表示包

11、含實際數(shù)據(jù)了，它也還可以有其他包含元數(shù)據(jù)的表示。 如在線書店為每本書提供該書電子版與評論兩種表示 表示的選擇信息可以放在HTTP報頭或URI中。恒生電子股份有限公司 | 大多數(shù)表示是超媒體(hypermedia)的，它不僅包含數(shù)據(jù)，還包含指向其它資源的鏈接。 Roy Fielding博士論文中指出：“將超媒體作為應用狀態(tài)的引擎”。即客戶端應用狀態(tài)在服務器提供的“超媒體”的指引下發(fā)生變遷。恒生電子股份有限公司 | 可尋址性(addressability) 無狀態(tài)性(statelessness) 連通性(connectedness) 統(tǒng)一接口(uniforminterface)恒生電子股份有限公司

12、 | 資源是通過URI暴露的，URI是可以尋址的。http:/ “瀏覽器打開google網(wǎng)站，搜索框輸入”陳老師”，點擊搜索。 服務器所能提供的每一則有價值的信息都應該作為資源來發(fā)布。 區(qū)別資源的可尋址與應用的可尋址：許多Web應用不是像Web一樣可尋址的，尤其是Ajax應用。如Gmail Web服務是可尋址的，不過調用該服務的Gmail Web應用不是可尋址的。恒生電子股份有限公司 | 狀態(tài)分兩種：應用狀態(tài)(applicationstate)和資源狀態(tài)(resourcestate)。前者保存在客戶端，后者保存在服務端。 每個HTTP請求是完全孤立。請求包含服務器實現(xiàn)該請求的全部信息，不依賴于

13、之前某個請求。 無狀態(tài)性意味著服務端不應保存應用狀態(tài)，客戶端應當管理自己的應用狀態(tài)。恒生電子股份有限公司 | 資源的表示“具有鏈接”的特性即連通性，它要求資源應當通過它們的表示彼此鏈接起來。 HTTP會話的當前狀態(tài)不是作為資源狀態(tài)保存在服務器上的，而是被客戶端作為應用狀態(tài)來跟蹤的。恒生電子股份有限公司 | 四個常見操作接口： 獲取資源的一個表示：HTTP GET 創(chuàng)建一個新資源：向一個新URI發(fā)送HTTP PUT，或向一個已有的URI發(fā)送HTTP POST 修改已有資源：向已有URI發(fā)送HTTP PUT 刪除已有資源：HTTP DELETE 兩個輔助操作接口： 獲取的一個只包含元數(shù)據(jù)的表示：H

14、TTP HEAD 查看一個資源支持那些HTTP方法：HTTP OPTIONS 安全性與冪等性： GET和HEAD請求是安全的 GET、HEAD、PUT和DELETE請求是冪等的恒生電子股份有限公司 | 創(chuàng)建資源時，PUT與POST的區(qū)別： 若客戶端決定新資源的URI用PUT 若服務器決定新資源的URI用POST 在一個博客系統(tǒng)中使用PUT與POST的比較：整個博客資源(/weblogs/myweblog)博客里一片文章資源(/weblogs/myweblog/entries/1)恒生電子股份有限公司 |恒生電子股份有限公司 |1.規(guī)劃數(shù)據(jù)集2.將數(shù)據(jù)集劃分為資源 3.設計URI為資源命名 4.

15、暴露一個統(tǒng)一接口的子集 5.設計來自客戶端的表示 6.設計發(fā)給客戶端的表示 7.用超鏈接和表單把資源與已有資源聯(lián)系起來 8.考慮有哪些典型的事件經(jīng)過 9.考慮可能出現(xiàn)的錯誤情況恒生電子股份有限公司 | 案例描述 顧客 與 服務員： 光臨KFC，排隊等候，查看食品列表，點餐，生成訂單，付款，在旁等候，下一位。 服務員 與 食品加工師： 接受訂單，制作食品，完成后遞交食品，下一個訂單。 服務員 與 顧客： 交付食品，顧客去享用食物。 恒生電子股份有限公司 | 顧客狀態(tài)機 食品加工師狀態(tài)機訂餐訂餐OK支付支付OK食物食物OK選定訂單選定訂單食物食物OK恒生電子股份有限公司 | 資源 URI 食物清單

16、(food list) http:/KFCS 請求 GET /foodlist HTTP 1.1 Host： KFCS Accept：application/xmll 響應 200 OK Content-Type：application/xml 恒生電子股份有限公司 | 資源 URI 訂單(order) http:/KFCS 請求 POST /order HTTP 1.1 cocol 響應 201 Created Location： http:/KFCS Content-Type：application/xml coco5.00 恒生電子股份有限公司 | 資源 URI 訂單(order/123

17、) http:/KFCS 可選請求 OPTIONS /order/123 HTTP 1.1l 可選響應 200 OK Allow: GET, PUTl 請求 PUT /order/123 HTTP 1.1 Expect: 100-Continuel 響應 200 OK 。 409 Conflict 。 使用OPTIONS 也未必能避免競爭 為可選請求 恒生電子股份有限公司 | 資源 URI 付款(payment/order/123) http:/KFCS 請求 PUT / payment/order/123 HTTP 1.1 Authorization: 123456 03/11 leo 5.

18、00l 響應 201 Created Location： http:/KFCS 意外 400 無法理解 401 認證失敗 PUT 冪等性 恒生電子股份有限公司 | 食品加工師輪詢獲取訂單，然后選定一個訂單，制作完成，再次輪詢。 輪詢的可伸縮性差，Web的輪詢機制如何解決？ 資源 URL 所有訂單(orders) http:/KFCS 請求 GET /orders HTTP 1.1 響應 200 OK .l 緩存機制 代理 本地 緩存時間恒生電子股份有限公司 | 資源 URI 訂單(order/123) http:/KFCS 請求 PUT /order/123 HTTP 1.1 更該狀態(tài)為處理中

19、 dealingl 響應 201 Createdl 影響 無法提交除GET外的請求 恒生電子股份有限公司 | 資源 URI 訂單(order/123) http:/KFCS 請求 DELETE /order/123 HTTP 1.1l 響應 200 OK 恒生電子股份有限公司 | 我們可以用Web來描述所有必需的交互。我們可以利用現(xiàn)有的Web模型處理一些簡單的意外的事（例如無法修改處理中或已處理完畢的訂單），而不必自己發(fā)明新的異?；蝈e誤處理機制我們所需的一切都是HTTP現(xiàn)成提供的。而且，即便發(fā)生了那些不愉快的事，客戶端仍然可以向它們的目標邁進。 HTTP提供的特性起初看來是無關緊要的。但這個協(xié)議現(xiàn)在已經(jīng)取得廣泛的一致、并得到廣泛的部署了，而且所有的軟件與硬件都能一定程度上理解它。當 我