Rest架構(gòu)與案例.ppt

1、REST架構(gòu)與案例分析,大綱,回顧Web的發(fā)展 HTTP 主流Web服務(wù)介紹 REST抽象概念 REST式架構(gòu) - ROA REST案例分析 REST式服務(wù)框架- Restlet,回顧Web的發(fā)展,HTTP(HypertextTransferProtocol) 超文本傳輸協(xié)議？NO，超文本轉(zhuǎn)移協(xié)議！ URI / URL Web1.0 靜態(tài)(只讀)倉庫 Web2.0 雙向，交互 Web3.0 數(shù)據(jù)化，服務(wù)化，平臺化 HTML JavaScript 富客戶端(Flex Silverlight) SOAP,HTTP 把文檔裝入信封,客戶端,服務(wù)器,響應(yīng),請求,HTTP請求,方法(method):表示

2、客戶端希望服務(wù)器如何處理該信封。有GET、POST、PUT、DELETE、HEAD、OPTION、TRACE和CONNECT八個方法。 路徑(path):請求鏈接里主機(jī)名后面部分，即信封上的地址。 請求報(bào)頭(request headers):一組起元數(shù)據(jù)作用的鍵值對，類似信封上貼的標(biāo)簽信息。HTTP除定義了一套標(biāo)準(zhǔn)報(bào)頭外，程序也可以自己定義報(bào)頭。 實(shí)體主體(entity-body):也稱作文檔或表示，即信封里的文檔。一般情況下，請求實(shí)體主體可為空。,HTTP響應(yīng),響應(yīng)代碼(response code):通知客戶端請求成功或失敗，以及如何處理信封里的內(nèi)容。 響應(yīng)報(bào)頭(response heade

3、r):類似請求報(bào)頭。 實(shí)體主體(entity-body):同樣是放在信封里的文檔，但絕大多數(shù)情況它不會為空。,HTTP報(bào)頭,標(biāo)準(zhǔn)報(bào)頭 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-Authenticate Date Cache-Control 非標(biāo)準(zhǔn)報(bào)頭 Co

4、okie Set-Cookie X-WSSE 自定義報(bào)頭 不重新發(fā)明已存在的報(bào)頭 不將應(yīng)該放在實(shí)體主體里的信息放進(jìn)報(bào)頭 命名遵循慣例，名稱以“X-”開頭,HTTP響應(yīng)代碼,狀態(tài)碼(3位數(shù)字)分類 1xx:通知僅在與HTTP服務(wù)器溝通時(shí)使用 2xx:成功成功收到、理解和接受動作 200(“OK”)、201(“Created”)、204(“No Content”) 3xx:重定向?yàn)橥瓿烧埱?，必須進(jìn)一步采取措施 301(“Moved Permanently”)、303(“See Other”) 4xx:客戶端錯誤請求包含錯誤的語法或不能完成 400(“Bad Request”)、401(“Unaut

5、horized”)、403(“Forbidden”) 404(“Not Found”)、405(“Method Not Allowed”) 5xx:服務(wù)器端錯誤服務(wù)器不能完成明顯合理的請求 500(“Internal Server Error”)、503(“Service Unavailable”),HTTP圖示,主流WEB服務(wù)架構(gòu),REST式面向資源的架構(gòu) 具備Web特征的服務(wù)：靜態(tài)網(wǎng)站、許多未采用SOAP的只讀Web服務(wù)、許多只讀型Web應(yīng)用等 PRC式架構(gòu) 所有采用XML-RPC遺留協(xié)議的服務(wù)，幾乎所有的SOAP服務(wù) REST-RPC混合架構(gòu) 大部分Web應(yīng)用，大量采用MVC模式的Web

6、應(yīng)用,REST簡介,REST(Representational State Transfer) 表述性狀態(tài)轉(zhuǎn)移，一種架構(gòu)風(fēng)格 不是一個具體的標(biāo)準(zhǔn)或者架構(gòu)，只是一套設(shè)計(jì)原則和一種架構(gòu)風(fēng)格 HTTP是這種架構(gòu)風(fēng)格的實(shí)現(xiàn) 一種真實(shí)描述Web的方式，不被特定時(shí)期的特定應(yīng)用程序概念歪曲，是對Web的本質(zhì)回歸 提供區(qū)分良好實(shí)踐和糟糕實(shí)踐的途徑：判斷特定實(shí)踐是否與Web架構(gòu)一致,REST抽象概念 資源,URI規(guī)范(RFC 2396)： “資源可以是任何有標(biāo)示的東西” “并非所有的資源都是通過網(wǎng)絡(luò)能夠獲取的” 任何事物，只要有被引用的必要，就是一個資源(resource)。它可以是一個實(shí)物，也可以是一個抽象的

7、概念。 通常一個資源是某個可以存放在計(jì)算機(jī)上并體現(xiàn)為比特流的事物。在Web中，可以這樣認(rèn)為資源是URI標(biāo)示的東西。,REST抽象概念 表示,資源和表示不是一碼事。Web上獲取的不是資源，而是資源的表示。 對于給定的資源，可以有很多不同的表示。,REST抽象概念 狀態(tài),在客戶-服務(wù)端模式下，讓客戶端維護(hù)應(yīng)用狀態(tài)，并確保服務(wù)端向服務(wù)器發(fā)出的請求都包含理解請求所需的全部信息，而服務(wù)器不應(yīng)該維護(hù)該狀態(tài)。 REST式解決方案是使用URI。每個概念上獨(dú)立的資源都可使用單個URI，不希望通過Cookie或隱藏在有效負(fù)載的參數(shù)來提供額外信息。 例：查看john在某網(wǎng)站2008-10-10的所有文檔資料,RES

8、T架構(gòu),REST設(shè)計(jì)準(zhǔn)則,網(wǎng)絡(luò)上的所有事物都被抽象為資源 每個資源對應(yīng)一個唯一的資源標(biāo)識URI 通過HTTP協(xié)議方法作連接器對資源進(jìn)行操作 對資源的任何操作不改變資源標(biāo)識URI 所有的服務(wù)器操作都是無狀態(tài)的,違背REST的惡果,服務(wù)端必須維持狀態(tài) 難以對URI進(jìn)行緩存 應(yīng)用部署難以水平擴(kuò)展 存在安全隱患 數(shù)據(jù)與表象混雜 無法準(zhǔn)確表達(dá)與理解請求含義 對不同客戶端要分代碼處理 URI難以持久化 暴露技術(shù)實(shí)現(xiàn)且易變更URI 代碼方法入侵URI,REST式架構(gòu) - ROA,面向資源的架構(gòu)(Resource-Oriented Architecture，ROA) 一個具體的REST式架構(gòu) 一種把實(shí)際問題轉(zhuǎn)

9、換成REST式Web服務(wù)的方法,ROA的四個概念,資源 資源的名稱(URI) 資源的表示 資源間的鏈接,一些資源的例子,某軟件的1.0.3版 一張杭州旅游地圖 QC中某個項(xiàng)目的Bug列表 某某公司04季度的營業(yè)額 一個風(fēng)險(xiǎn)點(diǎn)或一個風(fēng)險(xiǎn)模型 某張報(bào)表某個單元格的內(nèi)容 一個流程中的一個節(jié)點(diǎn)任務(wù) 陳老師與女明星的關(guān)系 等等,URI與資源的關(guān)系,URI既是資源的名稱，也是資源的地址。 一個資源必須至少有一個URI，而一個URI只能指示一個資源。 任何兩個資源不可能是同一個。 兩個不同的資源在某一時(shí)期可能指向同樣的數(shù)據(jù)。 同一資源具有多個URIs的雖然能讓引用變得更加容易，但壞處是將產(chǎn)生“稀釋效應(yīng)”，客

10、戶端無法自動驗(yàn)證它們是指向同一個資源。,資源的表示,對于一個本身就是一些數(shù)據(jù)項(xiàng)的資源，最容易想到的一個表示就是這些數(shù)據(jù)本身。 如HTML格式的網(wǎng)頁新聞 對于代表實(shí)物或其他難以歸結(jié)為信息的事物，其表示就是關(guān)于資源的狀態(tài)的任何有用信息。 如“連上Web的自動飲料機(jī)”提供關(guān)于實(shí)物飲料的數(shù)據(jù) 即使在一個對象的諸多表示中，已經(jīng)有一個表示包含實(shí)際數(shù)據(jù)了，它也還可以有其他包含元數(shù)據(jù)的表示。 如在線書店為每本書提供該書電子版與評論兩種表示 表示的選擇信息可以放在HTTP報(bào)頭或URI中。,資源間的鏈接,大多數(shù)表示是超媒體(hypermedia)的，它不僅包含數(shù)據(jù)，還包含指向其它資源的鏈接。 Roy Fieldi

11、ng博士論文中指出：“將超媒體作為應(yīng)用狀態(tài)的引擎”。即客戶端應(yīng)用狀態(tài)在服務(wù)器提供的“超媒體”的指引下發(fā)生變遷。,ROA四個屬性（特征標(biāo)志）,可尋址性(addressability) 無狀態(tài)性(statelessness) 連通性(connectedness) 統(tǒng)一接口(uniform interface),可尋址性,資源是通過URI暴露的，URI是可以尋址的。 “瀏覽器打開google網(wǎng)站，搜索框輸入”陳老師”，點(diǎn)擊搜索。 服務(wù)器所能提供的每一則有價(jià)值的信息都應(yīng)該作為資源來發(fā)布。 區(qū)別資源的可尋址與應(yīng)用的可尋址：許多Web應(yīng)用不是像Web一樣可尋址的，尤其是Ajax應(yīng)用。 如Gmail Web

12、服務(wù)是可尋址的，不過調(diào)用該服務(wù)的Gmail Web應(yīng)用不是可尋址的。,無狀態(tài)性,狀態(tài)分兩種：應(yīng)用狀態(tài)(application state)和資源狀態(tài)(resource state)。前者保存在客戶端，后者保存在服務(wù)端。 每個HTTP請求是完全孤立。請求包含服務(wù)器實(shí)現(xiàn)該請求的全部信息，不依賴于之前某個請求。 無狀態(tài)性意味著服務(wù)端不應(yīng)保存應(yīng)用狀態(tài)，客戶端應(yīng)當(dāng)管理自己的應(yīng)用狀態(tài)。,連通性,資源的表示“具有鏈接”的特性即連通性，它要求資源應(yīng)當(dāng)通過它們的表示彼此鏈接起來。 HTTP會話的當(dāng)前狀態(tài)不是作為資源狀態(tài)保存在服務(wù)器上的，而是被客戶端作為應(yīng)用狀態(tài)來跟蹤的。,統(tǒng)一接口,四個常見操作接口： 獲取資源的

13、一個表示：HTTP GET 創(chuàng)建一個新資源：向一個新URI發(fā)送HTTP PUT，或向一個已有的URI發(fā)送HTTP POST 修改已有資源：向已有URI發(fā)送HTTP PUT 刪除已有資源：HTTP DELETE 兩個輔助操作接口： 獲取的一個只包含元數(shù)據(jù)的表示：HTTP HEAD 查看一個資源支持那些HTTP方法：HTTP OPTIONS 安全性與冪等性： GET和HEAD請求是安全的 GET、HEAD、PUT和DELETE請求是冪等的,PUT與POST創(chuàng)建資源,創(chuàng)建資源時(shí)，PUT與POST的區(qū)別： 若客戶端決定新資源的URI用PUT 若服務(wù)器決定新資源的URI用POST 在一個博客系統(tǒng)中使用P

14、UT與POST的比較： 整個博客資源(/weblogs/myweblog) 博客里一片文章資源(/weblogs/myweblog/entries/1),使用PUT與POST比較,ROA設(shè)計(jì)步驟,1.規(guī)劃數(shù)據(jù)集 2.將數(shù)據(jù)集劃分為資源 3.設(shè)計(jì)URI為資源命名 4.暴露一個統(tǒng)一接口的子集 5.設(shè)計(jì)來自客戶端的表示 6.設(shè)計(jì)發(fā)給客戶端的表示 7.用超鏈接和表單把資源與已有資源聯(lián)系起來 8.考慮有哪些典型的事件經(jīng)過 9.考慮可能出現(xiàn)的錯誤情況,肯德基REST案例,案例描述 顧客 與 服務(wù)員： 光臨KFC，排隊(duì)等候，查看食品列表，點(diǎn)餐，生成訂單，付款，在旁等候，下一位。 服務(wù)員 與 食品加工師： 接

15、受訂單，制作食品，完成后遞交食品，下一個訂單。 服務(wù)員 與 顧客： 交付食品，顧客去享用食物。,狀態(tài)機(jī),顧客狀態(tài)機(jī) 食品加工師狀態(tài)機(jī),訂餐OK,支付OK,食物OK,選定訂單,食物OK,看看有哪些食物,資源 URI 食物清單(food list) http:/KFCS 請求 GET /foodlist HTTP 1.1 Host： KFCS Accept：application/xml 響應(yīng) 200 OK Content-Type：application/xml ,下訂單吧,資源 URI 訂單(order) http:/KFCS 請求 POST /order HTTP 1.1 coco 響應(yīng) 2

16、01 Created Location： http:/KFCS Content-Type：application/xml coco5.00 ,還想要點(diǎn)什么,資源 URI 訂單(order/123) http:/KFCS 可選請求 OPTIONS /order/123 HTTP 1.1 可選響應(yīng) 200 OK Allow: GET, PUT 請求 PUT /order/123 HTTP 1.1 Expect: 100-Continue 響應(yīng) 200 OK 。 409 Conflict 。 使用OPTIONS 也未必能避免競爭 為可選請求,OK 付款吧,資源 URI 付款(payment/orde

17、r/123) http:/KFCS 請求 PUT / payment/order/123 HTTP 1.1 Authorization: 123456 03/11 leo 5.00 響應(yīng) 201 Created Location： http:/KFCS 意外 400 無法理解 401 認(rèn)證失敗 PUT 冪等性,食品加工師的工作,食品加工師輪詢獲取訂單，然后選定一個訂單，制作完成，再次輪詢。 輪詢的可伸縮性差，Web的輪詢機(jī)制如何解決？ 資源 URL 所有訂單(orders) http:/KFCS 請求 GET /orders HTTP 1.1 響應(yīng) 200 OK . 緩存機(jī)制 代理 本地 緩存

18、時(shí)間,制作食品,資源 URI 訂單(order/123) http:/KFCS 請求 PUT /order/123 HTTP 1.1 更該狀態(tài)為處理中 dealing 響應(yīng) 201 Created 影響 無法提交除GET外的請求,食品完成,資源 URI 訂單(order/123) http:/KFCS 請求 DELETE /order/123 HTTP 1.1 響應(yīng) 200 OK,結(jié)論,我們可以用Web來描述所有必需的交互。我們可以利用現(xiàn)有的Web模型處理一些簡單的意外的事（例如無法修改處理中或已處理完畢的訂單），而不必自己發(fā)明新的異?；蝈e誤處理機(jī)制我們所需的一切都是HTTP現(xiàn)成提供的。而且，即便發(fā)生了那些不愉快的事，客戶端仍然可以向它們的目標(biāo)邁進(jìn)。 HTTP提供的特性起初看來是無關(guān)緊要的。但這個協(xié)議現(xiàn)在已經(jīng)取得廣泛的一致、并得到廣泛的部署了，而且所有的軟件與硬件都能一定程度上理解它。當(dāng) 我們看到其他分布