掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
RESTful Web APIs中文版 版權信息
- ISBN：9787121231155
- 條形碼：9787121231155 ; 978-7-121-23115-5
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
RESTful Web APIs中文版 本書特色
《restful web apis中文版》是針對restful api的實用指南，通過展示各種用來創建高可用應用的強大工具，講解rest的深層原理，以及介紹基于超媒體api的策略，使讀者得以在將上述內容融會貫通后，設計出讓客戶高度滿意的restful的web api。《restful web apis中文版》極具權威性與前瞻性，既代表了api領域的*前沿趨勢，也覆蓋了api領域的*重要實踐。 《restful web apis中文版》適合所有從事web開發和架構工作的讀者閱讀參考。
RESTful Web APIs中文版 內容簡介
本書是針對RESTful API的實用指南，通過展示各種用來創建高可用應用的強大工具，講解REST的深層原理，以及介紹基于超媒體API的策略，使讀者得以在將上述內容融會貫通后，設計出讓客戶高度滿意的RESTful的web API。本書極具權威性與前瞻性，既代表了API領域的*前沿趨勢，也覆蓋了API領域的*重要實踐。
RESTful Web APIs中文版 目錄
序 xix
前言 xxi
第1章 網上沖浪
場景1 ：廣告牌
資源和表述
可尋址性
場景2 ：主頁
短會話（short session）
自描述消息（self-descriptive message）
場景3 ：鏈接
標準方法
場景4 ：表單和重定向
應用狀態（application state）
資源狀態（resource state）
連通性（connectedness）
與眾不同的web
web api 落后于web
語義挑戰
第2章 一個簡單的api
http get ：安全的投注
如何讀取http 響應
json
collection+json
向api 寫入數據
http post: 資源是如何生成的
由約束帶來解放
應用語義所產生的語義鴻溝
第3章 資源和表述
萬物皆可為資源
表述描述資源狀態
往來穿梭的表述
資源有多重表述
http 協議語義（protocol semantics）
get
delete
冪等性（idempotence）
post-to-append
put
patch
link 和unlink
head
options
overloaded post
應該使用哪些方法？
第4章 超媒體
將html 作為超媒體格式
uri 模板
uri vs url
link 報頭
超媒體的作用
引導請求
對響應做出承諾
工作流控制
當心冒牌的超媒體！
語義挑戰：我們該怎么做？
第5章 領域特定設計
maze+xml ：領域特定設計
maze+xml 是如何工作的
鏈接關系
訪問鏈接來改變應用狀態
迷宮集合
maze+xml 是api 嗎？
客戶端1 ：游戲
maze+xml 服務器
客戶端2 ：地圖生成器
客戶端3 ：吹牛者
客戶端做自己想要做的事
對標準進行擴展
地圖生成器的缺陷
修復（以及修復后的瑕疵）
迷宮的暗喻
解決語義鴻溝
領域特定設計在哪里？
*終的獎賞
報頭中的超媒體
抄襲應用語義
如果找不到相關的領域特定設計，不要自己制造
api 客戶端的種類
人類驅動的客戶端
自動化客戶端
第6章 集合模式（collection pattern）
什么是集合？
鏈向子項的集合
collection+json
子項的表示
寫入模板（write template）
搜索模板
一個（通用的）集合是如何工作的
get
post-to-append
put 和patch
delete
分頁
搜索表單
atom 發布協議（atompub）
atompub 插件標準
為什么不是每個人都選擇使用atompub ？
語義挑戰：我們應該怎么做？
第7章 純- 超媒體設計
為什么是html?
html 的能力
超媒體控件
應用語義插件
微格式
hmaze 微格式
微數據
改變資源狀態
為表單添加應用語義
與超媒體相對是普通媒體
html 的局限性
拯救者html5?
超文本應用語言
siren
語義挑戰：我們現在要怎么做？
第8章 profile
客戶端如何找尋文檔？
什么是profile ？
鏈接到profile
profile 鏈接關系
profile 媒體類型參數
特殊用途的超媒體控件
profile 對協議語義的描述
profile 對應用語義的描述
鏈接關系
不安全的鏈接關系
語義描述符
xmdp ：首個機器可讀的profile 格式
alps
alps 的優勢
alps 并不是萬金油
json-ld
內嵌的文檔
總結
第9章 api 設計流程
兩個步驟的設計流程
七步驟設計流程
第1步：羅列語義描述符
第2步：畫狀態圖
第3步：調整命名
第4步：選擇一種媒體類型
第5步：編寫profile
第6步：實現
第7步：發布
實例：you type it, we post it
羅列語義描述符
畫狀態圖
調整名稱
選擇一種媒體類型
編寫profile
設計建議
資源是實現的內部細節
不要掉入集合陷阱
不要從表述格式著手
url 設計并不重要
標準名稱優于自定義名稱
設計媒體類型
當你的api 改變時
為現有api 添加超媒體
改進基于xml 的api
值不值得？
alice 的第二次探險
場景1 ：沒有意義的表述
場景2 ：profile
alice 明白了
第10章 超媒體動物園
領域特定格式
maze+xml
opensearch
問題細節文檔
svg
voicexml
集合模式的格式
collection+json
atom 發布協議
odata
純超媒體格式
html
hal
link 報頭
location 和content-location 報頭
url 列表
json 主文檔（home documents）
link-template 報頭
wadl
xlink
xforms
geojson ：一個令人困惑的類型
geojson 沒有通用的超媒體控件
geojson 沒有媒體類型
從geojson 學習到的經驗
語義動物園
鏈接關系的iana 注冊表
微格式wiki
來自微格式wiki 的鏈接關系
第11章 api 中的http
新http/11 規范
響應碼
報頭
表述選擇
內容協商（content negotiation）
超媒體菜單
標準url（canonical url）
http 性能
緩存（caching）
條件get 請求（conditional get）
look-before-you-leap 請求
壓縮
部分get 請求（partial get）
pipelining
避免更新丟失問題
認證
www-authenticate 報頭和authorization 報頭
basic 認證
oauth
oauth 10 的缺點
oauth
何時不采用oauth
http擴展
patch 方法
link 和unlink 方法
webdav
http
第12章 資源描述和linked data
rdf
rdf 將url 作為uri 對待
什么時候使用描述策略
資源類型
rdf schema
linked data 運動
json-ld
將json-ld 作為一種表述格式
hydra
xrd 家族
xrd 和jrd
web 主機元數據文檔
webfinger
本體動物園（ontology zoo）
schemaorg rdf
foaf
vocaborg
總結：描述策略生機盎然！
第13章 coap: 嵌入式系統的rest
coap 請求
coap 響應
消息種類
延遲響應（delayed response）
多播消息（multicast message）
core link format
結論：非http 協議的rest
附錄a 狀態法典
附錄b http 報頭法典
附錄c 為api 設計者準備的fielding 論文導讀
詞匯表
前言 xxi
第1章 網上沖浪
場景1 ：廣告牌
資源和表述
可尋址性
場景2 ：主頁
短會話（short session）
自描述消息（self-descriptive message）
場景3 ：鏈接
標準方法
場景4 ：表單和重定向
應用狀態（application state）
資源狀態（resource state）
連通性（connectedness）
與眾不同的web
web api 落后于web
語義挑戰
第2章 一個簡單的api
http get ：安全的投注
如何讀取http 響應
json
collection+json
向api 寫入數據
http post: 資源是如何生成的
由約束帶來解放
應用語義所產生的語義鴻溝
第3章 資源和表述
萬物皆可為資源
表述描述資源狀態
往來穿梭的表述
資源有多重表述
http 協議語義（protocol semantics）
get
delete
冪等性（idempotence）
post-to-append
put
patch
link 和unlink
head
options
overloaded post
應該使用哪些方法？
第4章 超媒體
將html 作為超媒體格式
uri 模板
uri vs url
link 報頭
超媒體的作用
引導請求
對響應做出承諾
工作流控制
當心冒牌的超媒體！
語義挑戰：我們該怎么做？
第5章 領域特定設計
maze+xml ：領域特定設計
maze+xml 是如何工作的
鏈接關系
訪問鏈接來改變應用狀態
迷宮集合
maze+xml 是api 嗎？
客戶端1 ：游戲
maze+xml 服務器
客戶端2 ：地圖生成器
客戶端3 ：吹牛者
客戶端做自己想要做的事
對標準進行擴展
地圖生成器的缺陷
修復（以及修復后的瑕疵）
迷宮的暗喻
解決語義鴻溝
領域特定設計在哪里？
*終的獎賞
報頭中的超媒體
抄襲應用語義
如果找不到相關的領域特定設計，不要自己制造
api 客戶端的種類
人類驅動的客戶端
自動化客戶端
第6章 集合模式（collection pattern）
什么是集合？
鏈向子項的集合
collection+json
子項的表示
寫入模板（write template）
搜索模板
一個（通用的）集合是如何工作的
get
post-to-append
put 和patch
delete
分頁
搜索表單
atom 發布協議（atompub）
atompub 插件標準
為什么不是每個人都選擇使用atompub ？
語義挑戰：我們應該怎么做？
第7章 純- 超媒體設計
為什么是html?
html 的能力
超媒體控件
應用語義插件
微格式
hmaze 微格式
微數據
改變資源狀態
為表單添加應用語義
與超媒體相對是普通媒體
html 的局限性
拯救者html5?
超文本應用語言
siren
語義挑戰：我們現在要怎么做？
第8章 profile
客戶端如何找尋文檔？
什么是profile ？
鏈接到profile
profile 鏈接關系
profile 媒體類型參數
特殊用途的超媒體控件
profile 對協議語義的描述
profile 對應用語義的描述
鏈接關系
不安全的鏈接關系
語義描述符
xmdp ：首個機器可讀的profile 格式
alps
alps 的優勢
alps 并不是萬金油
json-ld
內嵌的文檔
總結
第9章 api 設計流程
兩個步驟的設計流程
七步驟設計流程
第1步：羅列語義描述符
第2步：畫狀態圖
第3步：調整命名
第4步：選擇一種媒體類型
第5步：編寫profile
第6步：實現
第7步：發布
實例：you type it, we post it
羅列語義描述符
畫狀態圖
調整名稱
選擇一種媒體類型
編寫profile
設計建議
資源是實現的內部細節
不要掉入集合陷阱
不要從表述格式著手
url 設計并不重要
標準名稱優于自定義名稱
設計媒體類型
當你的api 改變時
為現有api 添加超媒體
改進基于xml 的api
值不值得？
alice 的第二次探險
場景1 ：沒有意義的表述
場景2 ：profile
alice 明白了
第10章 超媒體動物園
領域特定格式
maze+xml
opensearch
問題細節文檔
svg
voicexml
集合模式的格式
collection+json
atom 發布協議
odata
純超媒體格式
html
hal
link 報頭
location 和content-location 報頭
url 列表
json 主文檔（home documents）
link-template 報頭
wadl
xlink
xforms
geojson ：一個令人困惑的類型
geojson 沒有通用的超媒體控件
geojson 沒有媒體類型
從geojson 學習到的經驗
語義動物園
鏈接關系的iana 注冊表
微格式wiki
來自微格式wiki 的鏈接關系
第11章 api 中的http
新http/11 規范
響應碼
報頭
表述選擇
內容協商（content negotiation）
超媒體菜單
標準url（canonical url）
http 性能
緩存（caching）
條件get 請求（conditional get）
look-before-you-leap 請求
壓縮
部分get 請求（partial get）
pipelining
避免更新丟失問題
認證
www-authenticate 報頭和authorization 報頭
basic 認證
oauth
oauth 10 的缺點
oauth
何時不采用oauth
http擴展
patch 方法
link 和unlink 方法
webdav
http
第12章 資源描述和linked data
rdf
rdf 將url 作為uri 對待
什么時候使用描述策略
資源類型
rdf schema
linked data 運動
json-ld
將json-ld 作為一種表述格式
hydra
xrd 家族
xrd 和jrd
web 主機元數據文檔
webfinger
本體動物園（ontology zoo）
schemaorg rdf
foaf
vocaborg
總結：描述策略生機盎然！
第13章 coap: 嵌入式系統的rest
coap 請求
coap 響應
消息種類
延遲響應（delayed response）
多播消息（multicast message）
core link format
結論：非http 協議的rest
附錄a 狀態法典
附錄b http 報頭法典
附錄c 為api 設計者準備的fielding 論文導讀
詞匯表
展開全部
RESTful Web APIs中文版 節選
“大多數軟件系統在創建時都有一個隱含的假設：整個系統處在一個實體的控制之下；或者至少參與到系統中的所有實體都向著一個共同目標行動，而不是有著各自不同的目標。當系統在互聯網上開放地運行時，無法安全地滿足這樣的假設。” ——RoyFielding ArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures“Discordia信徒應該一直使用官方的Discordian文檔編號系統。” ——MalaclypsetheYounger和LordOmarKhayyamRavenhurst 我要向你展示一種可以更好地進行分布式計算的方式，它使用了有史以來*成功的分布式系統，即萬維網的根本思想。如果你已經決定（或者你的經理已經決定）需要為你的公司發布一個webAPI的話，我希望你能夠讀一下這本書。不管在你計劃中的是一個公共的API，還是一個純粹的內部API，抑或是一個只有受信伙伴可以訪問的API——它們都可以從REST的哲學中受益。 如果你想學習如何編寫API客戶端的話，那么這本書對你來說并不是必要的。這是因為大多數現有的API設計都基于一些有著數年之久的假設，而這些假設正是我想要摧毀的。 大部分今天的API都有著一個很大的問題：一旦部署，它們將無法改變。有一些大名鼎鼎的API會在一次部署后多年保持靜態不變，即使圍繞它們的行業發生著改變，這是因為要改變它們非常困難。 但是RESTful架構是為掌控變化而設計的。萬維網由數百萬的網站組成，運行在數千種不同的服務器實現之上，并且經歷著周期性的重新設計。這些網站被數十億的用戶訪問著，而這些用戶使用著幾十種硬件平臺之上的數百種不同的客戶端實現。你的部署在一開始可能看上去不會如此混亂，但是當你的應用越發接近web的規模時，你將會看到越發相似的混亂景象。 要改變一個非常簡單的系統通常都是很容易的。在規模很小時，一個RESTful系統比一個一鍵式的解決方案（push-buttonsolution）需要花費更多預支的設計成本。但是當你的API逐漸成熟并開始發生變化時，你將會真正需要一些像REST這樣的方式來應對變化。 y一個商業上成功的API將保持連續多年的可用。一些API擁有數百甚至是數以千計的用戶。就算問題域只是偶然地發生變化，對客戶端帶來的累積效應將是非常大的。 y有一些API一直都在發生變化，新的數據元素和業務規則不斷地被添加進來。 y在某些API中，每個客戶端都可以通過改變工作流來使其適合自己的需求。即使API自身從不變化，每個客戶端對API的經歷（鑒于經歷不同的工作流）將會不同。 y編寫API客戶端的人通常不會和編寫服務器的人隸屬于同一個團隊。所有向公共開放的API都屬于這一類。 如果你不知道外部的客戶端是哪種類型的話，你需要在做出變化時格外小心——否則你就需要一個能夠在發生變化時保證不會破壞所有客戶端的設計。如果你為你的API復制了現有的設計，你將很可能只是在重復以往犯過的錯誤。不幸的是，大部分的改進發生在幕后，它們大都還處于實驗階段并需要經過漫長的標準流程。我將會在本書中討論到數十種特定的技術，包括很多還仍然處于開發之中。但是我的主要目標是要教會你REST的基本原則。通過對這些內容的學習，你將可以對任何實驗成果以及那些通過流程審核的標準善加利用。 這里有兩個我想在本書中嘗試解決的具體問題：重復的工作以及對超媒體的逃避。讓我們來看看它們。 重復的工作 現今已發布的API都是根據托管它們的公司的名字進行命名的。我們談論著“TwitterAPI”、“FacebookAPI”和“Google+API”。這三套API做著相似的事情。它們都擁一些用戶賬戶的概念，（在其他方面）它們都允許用戶向自己的賬戶發布文本信息。但是每個API都具有完全不同的設計，學習一個API并不能幫助你學習下一個。當然，Twitter、Facebook和Google都是互相競爭的大型公司，它們并不想讓你很容易地就學會它們競爭對手的API。但是小公司和非營利性組織也在做著相同的事。它們重新設計著自己的API，就好比從來沒有人在這方面有過相似的想法一樣，但是這干擾了它們想讓人們實際使用它們的API的目標。 讓我來向你展示一個例子吧。網站ProgrammableWeb（http：//www。programmableweb。com/）擁有著一個超過8000個API的目錄。當我正在編寫此書之時，它已經收錄了57種微博API——這些API的主要用途是向用戶的賬戶發布文本信息注2。很不錯，有57家公司在這個領域發布了API，但是我們真的需要57種不同的設計嗎？我們在這里討論并不是那些復雜難懂的業務，例如保險政策或法規守則，我們討論的只是向用戶賬號發布少量的文本信息。你想成為那個設計第58種微博API的人嗎？ *顯而易見的解決方案便是創建一個微博API的標準。但是我們已經有了一個可以很好工作的標準：Atom發布協議（AtomPublishingProtocol）。它發布于2005年，然而幾乎沒有人使用它。有一些關于API的原因，使得每個人都想從頭開始設計他們自己的API，即使從業務的角度來看這并沒有什么意義。 我不認為憑我一個人的力量就能結束這種無用功，但是我確實認為可以將問題分解成若干有意義的小塊，然后提供一些方式來讓新的API可以復用已經完成的這些工作。 超媒體很難 早在2007年，LeonardRichardson和SamRuby編寫了本書的前身，RESTfulWebServices(O‘Reilly)。那本書同樣也嘗試于解決兩個大的問題。其中一個問題已經被解決，而另一個卻沒有任何進展。 **個問題是：在2007年，在API設計的多個陣營中，REST學派正在與使用基于SOAP等重量級技術的對手學派進行對峙，他們忙于應對來自對方的對REST學派合理性的質疑。RESTfulWebServices一書的出現打破了這種對峙的僵局，有效地為RESTful設計原則防御了來自SOAP學派的進攻。 很好，這場對峙已經結束，而REST贏得了勝利。SOAPAPI仍在被使用著，不過僅限于那些起初支持SOAP學派的大公司。幾乎所有面向公眾的API口頭上都說自己遵守了RESTful原則。 這又將我們帶到了第二個問題：REST并不只是一個技術詞匯——它同樣還是一個營銷術語。在很長一段時間里，REST成了一個口號，它象征著任何站在SOAP學派對立面的勢力。任何沒有使用SOAP的API都將自己標榜為REST，即使它的設計與REST毫無關系甚至是違背了REST的基本原則。這樣做是錯誤的，是令人困惑的，它給REST這個技術詞匯帶來了一個壞名聲。 這種情況自2007年便有了較大的改善。每當我審視那些新的API，我看到了開發者們的工作，可以看得出，這些開發人員是理解那些我將在本書前幾章中解釋的概念的。今天大部分舉著REST大旗的開發者都理解資源和表述，理解如何使用URL來為資源命名，以及如何正確地使用HTTP方法。因此本書的前三章將不需要做過多的事情，只需讓新的開發者加速趕上我們即可。 但是在REST中，還有一個方面令大部分的開發人員仍然無法理解，即：超媒體。我們都理解Web環境中的超媒體。它只是作為代表鏈接的一個華麗的詞匯。網頁經過互相的鏈接，隨即產生了萬維網，萬維網便是由超媒體驅動的。但是，貌似只要在webAPI中涉及到超媒體，我們便有了心理障礙。這是一個大問題，因為超媒體是一項能讓webAPI優雅處理變化的特性。 從RESTfulWebAPIs一書的第４章開始，我的首要目標便是教會你超媒體的工作原理。如果你從未聽到過這個詞，我將會結合其他重要的REST概念向你講授該詞。如果你聽到過超媒體，但是這個概念嚇到了你，我將會盡我所能來為你建立勇氣。如果你無法將超媒體裝進你的大腦，我將會以各種我所能想到的方式來向你展示超媒體，直到你記住并理解它。 RESTfulWebServices一書也涉及到了超媒體，但是這并不是該書的重心所在。就算跳過該書的超媒體部分也可以照樣設計出一個功能性的API。相比之下，RESTfulWebAPIs則是一本真正有關超媒體的書。 我之所以這樣做是因為超媒體是REST*重要的一個方面，也是*不被理解的一個方面。在我們完全理解超媒體之前，REST將會被繼續視為一個營銷術語，而不是對處理分布式計算復雜性的一次認真的嘗試。 ……
RESTful Web APIs中文版 相關資料
“這是一本了不起的書！《restful web apis》覆蓋了當今api領域最重要的趨勢和實踐。”
——john musser programmableweb創始人
RESTful Web APIs中文版 作者簡介
Leonard Richardson， 《Ruby Cookbook》 （O’Reilly）一書的作者，曾 創建了包括Beautiful Soup在內 的多個開源代碼庫。Mike Amundsen 是包括《Building Hypermedia APIs with HTML5 and Node》（O’Reilly） 在內的十幾本為人所稱道的技術圖書的作者。 Sam Ruby 是W3C HTML工作組的聯合主席，同時也是IBM新 興技術組的一名高級技術人員。
書友推薦
- >
中國歷史的瞬間
- >
羅庸西南聯大授課錄
- >
有舍有得是人生
- >
羅曼·羅蘭讀書隨筆-精裝
- >
人文閱讀與收藏·良友文學叢書:一天的工作
- >
莉莉和章魚
- >
回憶愛瑪儂
- >
上帝之肋:男人的真實旅程
本類暢銷
