REST實(shí)戰(zhàn)

出版時(shí)間：2011-10 出版社：東南大學(xué)出版社作者：Jim Webber,Savas Parastatidis,Ian Robinson 頁數(shù)：388 譯者：李錕,俞黎敏,馬鈞,崔毅
Tag標(biāo)簽：無

內(nèi)容概要

為何典型的企業(yè)項(xiàng)目無法像你為Web所開發(fā)的項(xiàng)目那樣運(yùn)行得如此平滑？對(duì)于建造分布式和企業(yè)級(jí)的應(yīng)用來說，REST架構(gòu)風(fēng)格真地提供了一個(gè)可行的替代選擇嗎？
在《REST實(shí)戰(zhàn)》這本富有洞察力的書中，三位SOA專家對(duì)于REST進(jìn)行了講求實(shí)際的解釋，并且通過將Web的指導(dǎo)原理應(yīng)用到普通的企業(yè)計(jì)算問題中，向你展示了如何開發(fā)簡(jiǎn)單的、優(yōu)雅的分布式超媒體系統(tǒng)。你將會(huì)學(xué)習(xí)到很多技術(shù)，并且隨著一家典型的公司從最初的小企業(yè)逐漸成長(zhǎng)為全球化的企業(yè)，使用這些Web技術(shù)和模式來解決這家公司在成長(zhǎng)過程中產(chǎn)生的各種需求。本書由Jim
Webber等著。

作者簡(jiǎn)介

Jim
Webber，ThoughtWorks公司的一位技術(shù)主管，工作于可信賴的分布式系統(tǒng)。 Savas
Parastatidis，微軟公司的一位架構(gòu)師，工作于大規(guī)模的數(shù)據(jù)密集型和計(jì)算密集型應(yīng)用。 Ian
Robinson，ThoughtWorks公司的首席咨詢顧問，幫助客戶從奠基階段到運(yùn)營階段創(chuàng)建可持續(xù)的面向服務(wù)開發(fā)能力。

書籍目錄

序言
前言
第1章  將Web作為建造分布式系統(tǒng)的平臺(tái)
  Web的架構(gòu)
  從資源的角度思考
  從Web架構(gòu)到REST架構(gòu)風(fēng)格
  Web作為一個(gè)應(yīng)用平臺(tái)
  Web的友好性和Richardson的成熟度模型
  起航
第2章介紹  Restbucks：如何以Web風(fēng)格獲得一杯咖啡
  Restbucks：一家有著全球抱負(fù)的小咖啡店
  Web現(xiàn)身了
第3章  基礎(chǔ)的Web集成
  減肥的感覺真好！
  一個(gè)簡(jiǎn)單的咖啡訂購系統(tǒng)
  URI模板
  URI隧道技術(shù)
  POX：基于HTTP之上的普通老式XML
  開始行動(dòng)
第4章  CRUD式Web服務(wù)
  將Orcler(訂單)建模為資源
  建造CRUD式服務(wù)
  消費(fèi)CRUD式服務(wù)
  通過WADL自動(dòng)消費(fèi)服務(wù)
  CRuD雖好，但還可以更好
第5章  超媒體服務(wù)
  超媒體原則
  超媒體格式
  契約
  超媒體協(xié)議
  實(shí)現(xiàn)超媒體服務(wù)
  用Java建造訂購服務(wù)
  在.NET中建造訂購服務(wù)
  Ready、Set和Action
第6章  向外擴(kuò)展
  回到基礎(chǔ)
  創(chuàng)建可緩存的內(nèi)容
  在.NET中實(shí)現(xiàn)緩存
  保持新鮮
第7章  Atom聯(lián)合格式
  格式
  將Atom用于事件驅(qū)動(dòng)系統(tǒng)
  用Java建造Atom服務(wù)
  在.NET中創(chuàng)建Atom服務(wù)
  Atom無處不在？
  反思
第8章  Atom發(fā)布協(xié)議
  Atom發(fā)布協(xié)議
  使用AtomPub實(shí)現(xiàn)訂單履行
  在.NET中實(shí)現(xiàn)AtomPub
  一個(gè)多功能的協(xié)議
第9章  Web安全
  HTTP安全要點(diǎn)
  身份標(biāo)識(shí)和OpenID協(xié)議
  0Auth協(xié)議
  服務(wù)的黑客攻擊和防御
  最后的思考
第10章  語義
  語法vs.語義
  信息的結(jié)構(gòu)和表述
  語義網(wǎng)
  微格式
  鏈接數(shù)據(jù)和Web
  指導(dǎo)
第1 章  Web和WS-*協(xié)議棧
  Wleb Services是邪惡的？
  SOAP：全部真相
  wsDL：不過是另一種對(duì)象接口定義語言(Object IDL)
  兩個(gè)錯(cuò)誤疊加無法得到正確結(jié)果
  安全的，可靠的，事務(wù)性的
  Web services的安魂曲？
第12章  為Web建造案例
  更多的銀彈是不存在的
  建造并運(yùn)行基于Web的服務(wù)
  沒有度量就沒有架構(gòu)
  推銷Web
  出發(fā)去建造

章節(jié)摘錄

版權(quán)頁：   插圖：   安全性和冪等性 我們?cè)诘?章中了解到，GET請(qǐng)求很特殊，因?yàn)樗哂屑劝踩謨绲鹊奶匦?。PUT請(qǐng)求和DEL ETE請(qǐng)求都是冪等的，但是它們都不安全，POST請(qǐng)求則是既不安全也不冪等。只有GET請(qǐng)求在重復(fù)調(diào)用時(shí)能返回相同的結(jié)果，并且不會(huì)產(chǎn)生需要消費(fèi)者負(fù)責(zé)的副作用。 對(duì)于GET請(qǐng)求，重復(fù)發(fā)送失敗的請(qǐng)求不會(huì)改變應(yīng)用的整體行為。例如，如果分布式應(yīng)用的某個(gè)部分在GET操作過程中崩潰了，或者在收到對(duì)GET的響應(yīng)之前網(wǎng)絡(luò)中斷了，那么客戶只要重新發(fā)出同樣的請(qǐng)求，并不會(huì)改變它與服務(wù)器交互的語義。 籠統(tǒng)來講，PUT和DELETE請(qǐng)求也同樣如此。對(duì)某個(gè)資源的狀態(tài)進(jìn)行一次絕對(duì)更新或者徹底將它刪除，無論該操作是進(jìn)行一次還是多次，結(jié)果將都是一樣的。如果PUT和DELETE請(qǐng)求的失敗是因?yàn)樗矔r(shí)的網(wǎng)絡(luò)或者服務(wù)器出錯(cuò)（如503響應(yīng)），那么該操作就可以安全地重復(fù)。 然而，由于PUT和DELETE請(qǐng)求會(huì)有副作用（因?yàn)樗鼈儾皇前踩模?，如果服?wù)器一開始就拒絕了某個(gè)操作，可能就不能隨時(shí)重復(fù)該操作了。例如，我們已經(jīng)見過當(dāng)消費(fèi)者和服務(wù)看到的資源狀態(tài)不一致時(shí)如何產(chǎn)生409響應(yīng)的（僅僅重復(fù)執(zhí)行相同的交互是沒有用的）。不過，HTTP提供了其他有用的特性，當(dāng)狀態(tài)發(fā)生變化的時(shí)候，對(duì)我們會(huì)很有幫助。 校正資源狀態(tài) 在分布式應(yīng)用中，經(jīng)常會(huì)出現(xiàn)多個(gè)消費(fèi)者與同一個(gè)資源交互的情況，每一位消費(fèi)者都不理會(huì)其他人所做的修改。除了這些由消費(fèi)者驅(qū)動(dòng)的變化，內(nèi)部的服務(wù)行為也會(huì)導(dǎo)致資源狀態(tài)發(fā)生消費(fèi)者所不知道的變化。在這兩種情況下，消費(fèi)者對(duì)資源狀態(tài)的了解可能會(huì)變得與服務(wù)的資源狀態(tài)不一致。除了預(yù)期有些不一致之外，如果消費(fèi)者對(duì)資源狀態(tài)的了解沒有及時(shí)更新，它發(fā)出的變更請(qǐng)求就會(huì)得到不符合預(yù)期的結(jié)果，無論是重復(fù)計(jì)算代價(jià)昂貴的請(qǐng)求，還是覆蓋以及丟失其他消費(fèi)者的變更，都是如此。 HTTP提供了一種簡(jiǎn)單但強(qiáng)大的機(jī)制，可以按照實(shí)體標(biāo)簽（entity tag）與條件請(qǐng)求頭信息（conditional request header）的形式，對(duì)所期待的資源狀態(tài)進(jìn)行校正（并防止產(chǎn)生競(jìng)爭(zhēng)）。一個(gè)實(shí)體標(biāo)簽值或者說ETag，就是一個(gè)不透明的字符串令牌，使服務(wù)器與資源關(guān)聯(lián)起來，以便在資源的生命周期中唯一標(biāo)識(shí)其狀態(tài)。當(dāng)資源發(fā)生變化時(shí)，如果其頭信息中有一個(gè)或者多個(gè)發(fā)生變化，或者其實(shí)體消息體發(fā)生變化，實(shí)體標(biāo)簽就會(huì)相應(yīng)地發(fā)生變化，表明該狀態(tài)已經(jīng)被修改。 ETag用于將實(shí)體與同一個(gè)資源進(jìn)行對(duì)比。通過在條件請(qǐng)求頭信息（如If—Match或者If—None—Match請(qǐng)求頭信息）中提供一個(gè)實(shí)體標(biāo)簽值，消費(fèi)者就可以告訴服務(wù)器在應(yīng)用請(qǐng)求中提供的方法之前，應(yīng)該先測(cè)試一下與當(dāng)前資源狀態(tài)有關(guān)的先決條件。

編輯推薦

《REST實(shí)戰(zhàn):超媒體和系統(tǒng)架構(gòu)(中文版)》由東南大學(xué)出版社出版。

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

還沒讀過(86)
勉強(qiáng)可看(629)
一般般(107)
內(nèi)容豐富(4452)
強(qiáng)力推薦(365)

REST實(shí)戰(zhàn) PDF格式下載

用戶評(píng)論 (總計(jì)38條)

rest入門好書，與rest web service相比，rest web service更多是從概念上描述rest，加上rest實(shí)戰(zhàn)，正好，理念加實(shí)踐，學(xué)習(xí)rest
REST實(shí)戰(zhàn)必讀
速度很快，總體來說還不錯(cuò)吧，REST集中講解的是理論知識(shí)，看的一知半解的，phonegap這本講解的還是比較詳細(xì)的，還不錯(cuò)！
通過這本書學(xué)些REST風(fēng)格的Service編程還是非常好的
針對(duì)REST進(jìn)行了全方面的講解，非常全面。
不錯(cuò)，也有涉及到理論的，本來還以為只有實(shí)戰(zhàn)的，意外的收獲
非常不錯(cuò)的一本書，推薦購買，尤其對(duì)系統(tǒng)選型有用
老外好像很了解我，我就喜歡看這種理論和實(shí)際皆滲透講解的書。
告訴讀者what,why
這本書的理論性太強(qiáng)，但是如果想深入研究REST的話，這本書還是一本挺不錯(cuò)的入門讀物。
略讀了一下感覺還可以，就是翻譯水平問題：）這個(gè)你懂的，建議配合英文版一起讀
書的紙張質(zhì)量很好，字體復(fù)印的清晰。
作為學(xué)習(xí)用的可以看看
在讀在讀在讀
沒看還不知道如何
戰(zhàn)
翻譯的不是太通俗易懂，讀起來有一點(diǎn)費(fèi)勁！
現(xiàn)在還沒看多少，感覺還可以吧！
紙張很好，看著舒服
感覺看的不是很懂，從第一頁開始就一直期待著本書能夠告訴我更多，結(jié)果到看完才發(fā)現(xiàn)沒掌握多少關(guān)于REST的知識(shí)，失望。
翻譯的相當(dāng)差！?。?/li>
我想要Java的實(shí)現(xiàn)，書中****的較多。
這是一種新的架構(gòu)模式，簡(jiǎn)單有效AND性能好
此本書籍介紹給開發(fā)系統(tǒng)框架工程師閱讀有點(diǎn)幫助的
很喜歡，將很多思想串起來了。
還在看，挺不錯(cuò)的實(shí)戰(zhàn)書
東南大學(xué)出版社印刷質(zhì)量沒人郵出版社的好，有味；不過我注重的還是書的內(nèi)容的質(zhì)量，剛拿到貨，期待中。。。。
總體來書，理論性比較強(qiáng)。需要一定的web開發(fā)基礎(chǔ)。
還不錯(cuò)，算實(shí)用吧
翻譯錯(cuò)誤比較多，一定要搭配英文版看
不錯(cuò)倒是不錯(cuò)
國外實(shí)戰(zhàn)書籍
還沒來得及看，感覺不錯(cuò)！
一本值得去看的好書啊
　　不錯(cuò)得書，能夠讓人對(duì)rest有完全得認(rèn)識(shí)，從簡(jiǎn)單得crud式得服務(wù)，到多媒體式的服務(wù)得詳細(xì)講解，然后是緩存得實(shí)現(xiàn)，最后是atom得詳細(xì)講解，讓能夠?qū)eb得整個(gè)架構(gòu)有詳細(xì)得認(rèn)識(shí)，對(duì)超媒體和系統(tǒng)架構(gòu)都能夠有相關(guān)的詳細(xì)講解，值得一讀
　　原文：http://www.cnblogs.com/cathsfz/archive/2012/05/09/2493385.html
　　
　　最近 O’Reilly 搞活動(dòng)，我就半價(jià)買了一本《REST in Practice》。對(duì)于 O’Reilly 的書，我通常會(huì)對(duì)比 O’Reilly 打折后的價(jià)錢和 Kindle 版的價(jià)格，通常是那家更便宜就在那家買，但圖表或代碼比較多的我就會(huì)堅(jiān)持買 O’Reilly 的版本，因?yàn)?PDF 能夠最好地保存這些格式。
　　
　　回到 REST 的話題上。盡管這個(gè)概念 2000 年就被提出來了，2007 年成為了一個(gè)熱詞，隨后越來越多的服務(wù)都宣稱自己是 RESTful 的，但是到底真么做才是真正的 REST 我從來沒有自習(xí)學(xué)習(xí)過。由于 2007 年的時(shí)候 Ruby on Rails 也十分熱門，所以我以為 Rails 風(fēng)格的 CRUD API 就是 REST 了，同時(shí)對(duì)于外界關(guān)于「什么算是 REST 什么不算是 REST」的爭(zhēng)論沒怎么關(guān)心過。
　　
　　記得之前老趙提到過《REST in Practice》是本好書，所以我就收藏到 wish list 里面了，在 O’Reilly 打折時(shí)就下狠心買下來，然后看看爭(zhēng)論得如此多的 REST 到底是什么東東。書中提到 Richardson 的 REST 成熟度模型，通過這個(gè)模型你可以理解什么是 REST 什么不是 REST。這個(gè)模型是這樣子的：
　　
　　第 0 級(jí)服務(wù)：只使用一個(gè) URI 作為一個(gè)服務(wù)端口，也只使用一個(gè) HTTP 方法傳輸數(shù)據(jù)。大多數(shù) WS-* 服務(wù)都是這個(gè)級(jí)別的，XML-RPC 和 POX 也是。這種做法相當(dāng)于把 HTTP 這個(gè)應(yīng)用層協(xié)議降級(jí)為傳輸層協(xié)議用。HTTP 頭和有效載荷是完全隔離的，HTTP 頭只用于保證傳輸，不涉及業(yè)務(wù)邏輯；有效載荷包含全部業(yè)務(wù)邏輯，因此 API 可以無視 HTTP 頭中的任何信息。
　　
　　第 1 級(jí)服務(wù)：使用多個(gè) URI，不同的 URI 代表不同的調(diào)用入口，但只使用同一個(gè) HTTP 方法傳輸數(shù)據(jù)。
　　
　　第 2 級(jí)服務(wù)：使用多個(gè) URI，不同的 URI 代表不同的資源，同時(shí)使用多個(gè) HTTP 方法操作這些資源，例如使用 POST/GET/PUT/DELET 分別進(jìn)行 CRUD 操作。這時(shí)候 HTTP 頭和有效載荷都包含業(yè)務(wù)邏輯，例如 HTTP 方法對(duì)應(yīng) CRUD 操作，HTTP 狀態(tài)碼對(duì)應(yīng)操作結(jié)果的狀態(tài)。我們現(xiàn)在看到的大多數(shù)所謂 RESTful API 做到的也就是這個(gè)級(jí)別。
　　
　　第 3 級(jí)服務(wù)：使用超媒體（hypermedia）作為應(yīng)用狀態(tài)引擎。要解釋這個(gè)概念先要解釋什么是超媒體：
　　
　　我們已經(jīng)知道什么是多媒體（multimedia），以及什么是超文本（hypertext）。其中超文本特有的優(yōu)勢(shì)是擁有超鏈接（hyperlink）。如果我們把超鏈接引入到多媒體當(dāng)中去，那就得到了超媒體，因此關(guān)鍵角色還是超鏈接。使用超媒體作為應(yīng)用引擎狀態(tài)，意思是應(yīng)用引擎的狀態(tài)變更由客戶端訪問不同的超媒體資源驅(qū)動(dòng)。
　　
　　舉個(gè)例子來說，用戶在論壇的帖子列表點(diǎn)擊超鏈接進(jìn)入某個(gè)帖子，這時(shí)候?yàn)g覽器作為一個(gè)客戶端就會(huì)去 GET 這個(gè)帖子的鏈接 URI，應(yīng)用狀態(tài)就切換為顯示某個(gè)帖子了。接著用戶輸入回復(fù)提交表單，瀏覽器就會(huì)根據(jù) form 上面的 action 屬性 POST 內(nèi)容給目標(biāo) URI，應(yīng)用狀態(tài)就再一次發(fā)生切換，完成了回復(fù)的存儲(chǔ)。
　　
　　使用超媒體與前面第 1 級(jí)、第 2 級(jí)的顯著區(qū)別是，客戶端不再和 URI 緊耦合。在第 1 級(jí)或者第 2 級(jí)的應(yīng)用里面，客戶端都需要知道資源使用的 URI 模版（如 /orders/{id}），然后要操作什么樣的資源就生成什么樣的 URI。超媒體客戶端只知道入口 URI，之后的每一個(gè) URI 都是通過超鏈接獲得的。
　　
　　還是用上述論壇例子來解釋，假若這個(gè)論壇通過 Atom 協(xié)議支持非瀏覽器的客戶端訪問。客戶端是不需要知道論壇帖子的 URI 模版的，因?yàn)榭蛻舳丝梢酝ㄟ^帖子列表的 Atom 獲得帖子的超鏈接，然后在用戶選擇瀏覽帖子時(shí)獲取對(duì)應(yīng) URI 的內(nèi)容。獲取回來的結(jié)果不會(huì)帶有 form，但會(huì)帶有 <link rel="reply" />，通過這個(gè) link 客戶端又知道了用戶提交的回復(fù)應(yīng)該發(fā)往哪個(gè) URI。
　　
　　說完 Richardson 的成熟度模型，說說 REST 這篇論文作者 Roy Fielding 的回應(yīng)。Roy Fielding 說「只有使用了超媒體的才能算是 REST」。簡(jiǎn)單來說，他認(rèn)為第 3 級(jí)成熟度以外的都不算 REST。我個(gè)人的看法是，我支持 Roy Fielding 對(duì) REST 的嚴(yán)格定義，我也認(rèn)為一個(gè)真正使用了超媒體實(shí)現(xiàn)應(yīng)用狀態(tài)引擎的服務(wù)非常了不起，但是在普通 CRUD API 能滿足需求的情況下我覺得使用 CRUD API 也可以。
　　
　　這本書后面還講到了如何使用緩存來增加系統(tǒng)健壯性，如何使用 Atom 和 Atom 發(fā)布協(xié)議，如何使用 OpenID 和 OAuth 等認(rèn)證授權(quán)技術(shù)。因?yàn)檫@本書我還沒看完，所以這些內(nèi)容我也不好做評(píng)價(jià)。
　　
　　這本書總體來說寫得不錯(cuò)，但就是廢話稍微多了一點(diǎn)點(diǎn)。如果你跳著章節(jié)地去看，可能就不會(huì)覺得那是廢話了，因?yàn)槟闾暨x出來閱讀的部分都包含所有的信息。但如果你像我這樣從頭到尾地閱讀，就會(huì)覺得作者怎么前面提到過的事情后面還要再提及。
　　
　　此外這本書提供的大量 .NET 和 Java 代碼對(duì)我來說沒什么意義。我覺得這本書更多是寫給做企業(yè)服務(wù)的人看的，希望他們的思維模式能夠從企業(yè)環(huán)境里常見的 WS-* 跳出來，同時(shí)希望證明給他們看實(shí)現(xiàn) REST 是多么簡(jiǎn)單的事情。這對(duì)于天天研究互聯(lián)網(wǎng)服務(wù)的我來說沒什么必要，況且我也很久沒寫過 .NET 代碼了，所以各式各樣的示例代碼給我無視掉了。我覺得我知道這件事情 WCF 能做也就足夠了。
WS-* 服務(wù) 這個(gè)是什么。。。
Java的WebService相關(guān)的應(yīng)用棧

REST實(shí)戰(zhàn)

用戶評(píng)論 (總計(jì)38條)

推薦圖書

相關(guān)圖書