RESTful Web APIs中文版PDF电子书下载

第1章 网上冲浪 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

写入模板（WriteTemplate） 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

链接到Proffle 137

Proffle链接关系 137

Profile媒体类型参数 138

特殊用途的超媒体控件 139

Proffle对协议语义的描述 139

Proffle对应用语义的描述 140

链接关系 141

不安全的链接关系 142

语义描述符 142

XMDP：首个机器可读的Proffle格式 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

实例：YouType 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/1.1 规范 242

响应码 242

报头 243

表述选择 243

内容协商（Content Negotiation） 243

超媒体菜单 244

标准URL（Canonical URL） 245

HTTP性能 246

缓存（Caching） 246

条件GET请求（Conditional GET） 247

Look-Before-You-Leap请求 249

压缩 250

部分GET请求（Partial GET） 250

Pipelining 251

避免更新丢失问题 252

认证 254

WWW-Authenticate报头和Authorization报头 255

Basic认证 255

OAuth 1.0 256

OAuth 1.0的缺点 259

OAuth 2.0 260

何时不采用OAuth 261

HTTP扩展 261

PATCH方法 262

LINK和UNLINK方法 262

WebDAV 263

HTTP 2.0 264

第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

schema.org RDF 289

FOAF 290

vocab.org 290

总结：描述策略生机盎然！ 290

第13章 GoAP：嵌入式系统的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