RESTful Web APIs (中文版) RESTful Web APIs中文版

倫納德·理乍得森 (Leonard Richardson), 麥克·阿蒙森 (Mike Amundsen)

下單後立即進貨 (約4週~6週)

買這商品的人也買了...

相關主題

商品描述

近年來,REST的流行導致了各種“RESTful”API的巨大增長,但是這些API卻錯失了很多架構的好處。通過這本實用指南,你將可以學習到如何設計可用的、並能隨著時間不斷進化的REST API。通過專註於跨多種領域的解決方案,《RESTful Web APIs中文版》向你展示了該如何使用那些為成功的分佈式計算系統——萬維網而設計的工具,從而來創建強大且安全的應用。你將探索REST背後的概念,學習多種可用於創建基於超媒體API的策略,並在《RESTful Web APIs中文版》一步步的指導下整合你所學到的所有內容,從而去設計RESTful的web API。

審查了包括集合模式和純超媒體在內的API設計策略。
理解如何將超媒體與表述整合進一個一致的API。
探索XMDP和ALPS profile格式是如何幫助你應對web API的語義挑戰。
學習近二十多種標準化的超媒體數據格式。
應用在API實現中使用HTTP的實踐。
使用JSON-LD標準及其他Linked Data方法來創建web API。
理解在嵌入式系統使用REST的CoAP協議。

作者簡介

Leonard Richardson
《Ruby Cookbook》 (O'Reilly)一書的作者,曾創建了包括Beautiful Soup在內的多個開源代碼庫。


Mike Amundsen
包括《Building Hypermedia APIs with HTML5 and Node》(O'Reilly)在內的十幾本為人所稱道的技術圖書的作者。

目錄大綱

序ⅹⅸ 
前言ⅹⅹⅰ 

第1章網上沖浪

場景1 :廣告牌2 
資源和表述2 
可尋址性3 
場景2 :主頁3 
短會話(Short Session) 5 
自描述消息(self—descriptive message) 5 
場景3 :鏈接6 
標準方法8 
場景4 :表單和重定向9 
應用狀態(Application State) 11 
資源狀態(resource state) 12 
連通性(connectedness) 13 
與眾不同的Web 14 
Web API落後於Web 15 
語義挑戰16 

第2章一個簡單的API 17 

HTTP GET :安全的投注18 
如何讀取HTTP響應19 
JSON 20 
Collection+JSON 21 
向API寫入數據23 
HTTP POST:資源是如何生成的24 
由約束帶來解放26 
應用語義所產生的語義鴻溝27 

第3章資源和表述29 

萬物皆可為資源30 
表述描述資源狀態30 
往來穿梭的表述31 
資源有多重表述32 
HTTP協議語義(Protocol Semantics) 33 
GET 35 
DELETE 36 
冪等性(Idempotence) 36 
POST—to—Append 37 
PUT 38 
PATCH 39 
LINK和UNLINK 40 
HEAD 40 
OPTIONS 41 
Overloaded POST 41 
應該使用哪些方法?42 

第4章超媒體45 

將HTML作為超媒體格式46 
URI模板49 
URI vs URL 50 
Link報頭51 
超媒體的作用52 
引導請求52 
對響應做出承諾54 
工作流控制55 
當心冒牌的超媒體!56 
語義挑戰:我們該怎麼做?57 

第5章領域特定設計59 

Maze+XML :領域特定設計60 
Maze+XML是如何工作的61 
鏈接關係62 
訪問鏈接來改變應用狀態64 
迷宮集合65 
Maze+XML是API嗎?67 
客戶端1 :遊戲68 
Maze+XML服務器72 
客戶端2 :地圖生成器74 
客戶端3 :吹牛者76 
客戶端做自己想要做的事77 
對標准進行擴展77 
地圖生成器的缺陷80 
修復(以及修復後的瑕疵) 81 
迷宮的暗喻83 
解決語義鴻溝83 
領域特定設計在哪裡?83 
最終的獎賞84 
報頭中的超媒體84 
抄襲應用語義84 
如果找不到相關的領域特定設計,不要自己製造86 
API客戶端的種類86 
人類驅動的客戶端86 
自動化客戶端87 

第6章集合模式( Collection Pattern) 91 

什麼是集合?93 
鏈向子項的集合93 
Collection+JSON 94 
子項的表示95 
寫入模板(Write Template) 98 
搜索模板99 
一個(通用的)集合是如何工作的100 
GET 101 
POST—to—Append 101 
PUT和PATCH 101 
DELETE 102 
分頁102 
搜索表單103 
Atom發布協議(AtomPub) 103 
AtomPub插件標準105 
為什麼不是每個人都選擇使用AtomPub ?106 
語義挑戰:我們應該怎麼做?107 

第7章純—超媒體設計111 

為什麼是HTML?111 
HTML的能力112 
超媒體控件112 
應用語義插件113 
微格式115 
hMaze微格式116 
微數據118 
改變資源狀態119 
為表單添加應用語義121 
與超媒體相對是普通媒體125 
HTML的局限性126 
拯救者HTML5?127 
超文本應用語言128 
Siren 131 
語義挑戰:我們現在要怎麼做?133 

第8章Profile 135 

客戶端如何找尋文檔?136 
什麼是Profile ?137 
鏈接到Profile 137 
Profile鏈接關係137 
Profile媒體類型參數138 
特殊用途的超媒體控件139 
Profile對協議語義的描述139 
Profile對應用語義的描述140 
鏈接關係141 
不安全的鏈接關係142 
語義描述符142 
XMDP :首個機器可讀的Profile格式143 
ALPS 146 
ALPS的優勢150 
ALPS並不是萬金油152 
JSON—LD 153 
內嵌的文檔156 
總結158 

第9章API設計流程161 

兩個步驟的設計流程161 
七步驟設計流程162 
第1步:羅列語義描述符163 
第2步:畫狀態圖164 
第3步:調整命名168 
第4步:選擇一種媒體類型172 
第5步:編寫Profile 173 
第6步:實現174 
第7步:發布174 
實例:You Type It, We Post It 177 
羅列語義描述符177 
畫狀態圖178 
調整名稱179 
選擇一種媒體類型180 
編寫Profile 181 
設計建議182 
資源是實現的內部細節182 
不要掉入集合陷阱183 
不要從表述格式著手184 
URL設計並不重要184 
標準名稱優於自定義名稱186 
設計媒體類型187 
當你的API改 時189 
為現有API添加超媒體194 
改進基於XML的API 195 
值不值得?196 
Alice的第二次探險196 
場景1 :沒有意義的表述196 
場景2 :Profile 198 
Alice明白了200 

第10章超媒體動物園203 

領域特定格式204 
Maze+XML 204 
OpenSearch 205 
問題細節文檔205 
SVG 206 
VoiceXML 208 
集合模式的格式210 
Collection+JSON 211 
Atom發布協議211 
OData 212 
純超媒體格式219 
HTML 219 
HAL 220 
Link報頭222 
Location和Content—Location報頭222 
URL列表223 
JSON主文檔(Home Documents) 223 
Link—Template報頭224 
WADL 225 
XLink 226 
XForms 227 
GeoJSON :一個令人困惑的類型228 
GeoJSON沒有通用的超媒體控件230 
GeoJSON沒有媒體類型232 
從GeoJSON學習到的經驗233 
語義動物園234 
鏈接關係的IANA註冊表234 
微格式WiKi 235 
來自微格式Wiki的鏈接關係236 

第11章API中的HTTP 241 

新HTTP/11規範242 
響應碼242 
報頭243 
表述選擇243 
內容協商(Content Negotiation) 243 
超媒體菜單244 
標準URL(Canonical URL) 245 
HTTP性能246 
緩存(Caching) 246 
條件GET請求(Conditiona l GET) 247 
Look—Before—You—Leap請求249 
壓縮250 
部分GET請求(Partial GET) 250 
Pipelining 251 
避免更新丟失問題252 
認證254 
WWW—Authenticate報頭和Authorization報頭255 
Basic認證255 
OAuth 10256 
OAuth 10的缺點259 
OAuth 20260 
何時不採用OAuth 261 
HTTP擴展261 
PATCH方法262 
LINK和UNLINK方法262 
WebDAV 263 
HTTP 20264 

第12章資源描述和Linked Data 267 

RDF 268 
RDF將URL作為URI對待270 
什麼時候使用描述策略271 
資源類型273 
RDF Schema 274 
Linked Data運動277 
JSON—LD 278 
將JSON—LD作為一種表述格式279 
Hydra 280 
XRD家族285 
XRD和JRD 285 
Web主機元數據文檔286 
WebFinger 287 
本體動物園(Ontology Zoo) 289 
schemaorg RDF 289 
FOAF 290 
vocaborg 290 
總結:描述策略生機盎然!290

第13章CoAP:嵌入式系統的REST 293 

CoAP請求294 
CoAP響應294 
消息種類295 
延遲響應(Delayed Response) 296 
多播消息(Multicast Message) 296 
CoRE Link Format 297 

結論:非HTTP協議的REST 298 
附錄A狀態法典301 
附錄B HTTP報頭法典325 
附錄C為API設計者準備的Fielding論文導讀349 
詞彙表365