REST實戰(zhàn)

出版時間:2011-10  出版社:東南大學出版社  作者:Jim Webber,Savas Parastatidis,Ian Robinson  頁數:388  譯者:李錕,俞黎敏,馬鈞,崔毅  
Tag標簽:無  

內容概要

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

作者簡介

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

書籍目錄

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

章節(jié)摘錄

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

編輯推薦

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

圖書封面

圖書標簽Tags

評論、評分、閱讀與下載


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


用戶評論 (總計38條)

 
 

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

250萬本中文圖書簡介、評論、評分,PDF格式免費下載。 第一圖書網 手機版

京ICP備13047387號-7