RESTful Web APIs中文版
Leonard Richardson, Mike Amundsen
赵震一, 李哲 译
出版时间:2014年05月
页数:382
“这是一本了不起的书! RESTful Web APIs覆盖了当今API领域最重要的趋势和实践。”
—— John Musser,ProgrammableWeb创始人

近年来,REST的流行导致了各种“RESTful”API的巨大增长,但是这些API却错失了很多架构的好处。通过这本实用指南,你将可以学习到如何设计可用的,并能随着时间不断进化的REST API。通过专注于跨多种领域的解决方案,本书向你展示了该如何使用那些为世界上最成功的分布式计算系统——万维网而设计的工具,从而来创建强大且安全的应用。你将探索REST背后的概念,学习多种可用于创建基于超媒体API的策略,并在本书一步步的指导下整合你所学到的所有内容,从而去设计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在内的多个开源代码库。
MikeaAmundsen是包括《使用HTML5和Node构建超媒体API》(O’Reilly)在内的十几本为人所称道的技术图书的作者。
Sam Ruby是 W3C HTML工作组的联合主席,同时也是IBM新兴技术组的一名高级技术人员。
  1. 前言
  2. 第1章 网上冲浪
  3. 场景1:广告牌
  4. 资源和表述
  5. 可寻址性
  6. 场景2:主页
  7. 短会话(short session)
  8. 自描述消息(self-descriptive message)
  9. 场景3:链接
  10. 标准方法
  11. 场景4:表单和重定向
  12. 应用状态(application state)
  13. 资源状态(resource state)
  14. 连通性(connectedness)
  15. 与众不同的web
  16. web api落后于web
  17. 语义挑战
  18. 第2章 一个简单的api
  19. http get:安全的投注
  20. 如何读取http响应
  21. json
  22. collection+json
  23. 向api写入数据
  24. http post: 资源是如何生成的
  25. 由约束带来解放
  26. 应用语义所产生的语义鸿沟
  27. 第3章 资源和表述
  28. 万物皆可为资源
  29. 表述描述资源状态
  30. 往来穿梭的表述
  31. 资源有多重表述
  32. http协议语义(protocol semantics)
  33. get
  34. delete
  35. 幂等性(idempotence)
  36. post-to-append
  37. put
  38. patch
  39. link和unlink
  40. head
  41. options
  42. overloaded post
  43. 应该使用哪些方法?
  44. 第4章 超媒体
  45. 将html作为超媒体格式
  46. uri 模板
  47. uri vs url
  48. link报头
  49. 超媒体的作用
  50. 引导请求
  51. 对响应做出承诺
  52. 工作流控制
  53. 当心冒牌的超媒体!
  54. 语义挑战:我们该怎么做?
  55. 第5章 领域特定设计
  56. maze+xml:领域特定设计
  57. maze+xml是如何工作的
  58. 链接关系
  59. 访问链接来改变应用状态
  60. 迷宫集合
  61. maze+xml是api吗?
  62. 客户端1:游戏
  63. maze+xml服务器
  64. 客户端2:地图生成器
  65. 客户端3:吹牛者
  66. 客户端做自己想要做的事
  67. 对标准进行扩展
  68. 地图生成器的缺陷
  69. 修复(以及修复后的瑕疵)
  70. 迷宫的暗喻
  71. 解决语义鸿沟
  72. 领域特定设计在哪里?
  73. 最终的奖赏
  74. 报头中的超媒体
  75. 抄袭应用语义
  76. 如果找不到相关的领域特定设计,不要自己制造
  77. api客户端的种类
  78. 人类驱动的客户端
  79. 自动化客户端
  80. 第6章 集合模式(collection pattern)
  81. 什么是集合?
  82. 链向子项的集合
  83. collection+json
  84. 子项的表示
  85. 写入模板(write template)
  86. 搜索模板
  87. 一个(通用的)集合是如何工作的
  88. get
  89. post-to-append
  90. put和patch
  91. delete
  92. 分页
  93. 搜索表单
  94. atom发布协议(atompub)
  95. atompub插件标准
  96. 为什么不是每个人都选择使用atompub?
  97. 语义挑战:我们应该怎么做?
  98. 第7章 纯-超媒体设计
  99. 为什么是html?
  100. html的能力
  101. 超媒体控件
  102. 应用语义插件
  103. 微格式
  104. hmaze微格式
  105. 微数据
  106. 改变资源状态
  107. 为表单添加应用语义
  108. 与超媒体相对是普通媒体
  109. html的局限性
  110. 拯救者html5?
  111. 超文本应用语言
  112. siren
  113. 语义挑战:我们现在要怎么做?
  114. 第8章 profile
  115. 客户端如何找寻文档?
  116. 什么是profile ?
  117. 链接到profile
  118. profile链接关系
  119. profile媒体类型参数
  120. 特殊用途的超媒体控件
  121. profile对协议语义的描述
  122. profile对应用语义的描述
  123. 链接关系
  124. 不安全的链接关系
  125. 语义描述符
  126. xmdp:首个机器可读的profile格式
  127. alps
  128. alps的优势
  129. alps并不是万金油
  130. json-ld
  131. 内嵌的文档
  132. 总结
  133. 第9章 api设计流程
  134. 两个步骤的设计流程
  135. 七步骤设计流程
  136. 第1步:罗列语义描述符
  137. 第2步:画状态图
  138. 第3步:调整命名
  139. 第4步:选择一种媒体类型
  140. 第5步:编写profile
  141. 第6步:实现
  142. 第7步:发布
  143. 实例:you type it, we post it
  144. 罗列语义描述符
  145. 画状态图
  146. 调整名称
  147. 选择一种媒体类型
  148. 编写profile
  149. 设计建议
  150. 资源是实现的内部细节
  151. 不要掉入集合陷阱
  152. 不要从表述格式着手
  153. url设计并不重要
  154. 标准名称优于自定义名称
  155. 设计媒体类型
  156. 当你的api改变时
  157. 为现有api添加超媒体
  158. 改进基于xml的api
  159. 值不值得?
  160. alice的第二次探险
  161. 场景1:没有意义的表述
  162. 场景2:profile
  163. alice明白了
  164. 第10章 超媒体动物园
  165. 领域特定格式
  166. maze+xml
  167. opensearch
  168. 问题细节文档
  169. svg
  170. voicexml
  171. 集合模式的格式
  172. collection+json
  173. atom发布协议
  174. odata
  175. 纯超媒体格式
  176. html
  177. hal
  178. link报头
  179. location和content-location报头
  180. url列表
  181. json主文档(home documents)
  182. link-template报头
  183. wadl
  184. xlink
  185. xforms
  186. geojson:一个令人困惑的类型
  187. geojson没有通用的超媒体控件
  188. geojson没有媒体类型
  189. 从geojson学习到的经验
  190. 语义动物园
  191. 链接关系的iana注册表
  192. 微格式wiki
  193. 来自微格式wiki的链接关系
  194. 第11章 api中的http
  195. 新http/1.1规范
  196. 响应码
  197. 报头
  198. 表述选择
  199. 内容协商(content negotiation)
  200. 超媒体菜单
  201. 标准url(canonical url)
  202. http性能
  203. 缓存(caching)
  204. 条件get 请求(conditional get)
  205. look-before-you-leap请求
  206. 压缩
  207. 部分get请求(partial get)
  208. pipelining
  209. 避免更新丢失问题
  210. 认证
  211. www-authenticate报头和authorization报头
  212. basic认证
  213. oauth 1.0
  214. oauth 1.0的缺点
  215. oauth 2.0
  216. 何时不采用oauth
  217. http扩展
  218. patch方法
  219. link 和unlink方法
  220. webdav
  221. http 2.0
  222. 第12章 资源描述和linked data
  223. rdf
  224. rdf将url作为uri对待
  225. 什么时候使用描述策略
  226. 资源类型
  227. rdf schema
  228. linked data运动
  229. json-ld
  230. 将json-ld作为一种表述格式
  231. hydra
  232. xrd家族
  233. xrd和jrd
  234. web主机元数据文档
  235. webfinger
  236. 本体动物园(ontology zoo)
  237. schema.org rdf
  238. foaf
  239. vocab.org
  240. 总结:描述策略生机盎然!
  241. 第13章 coap: 嵌入式系统的rest
  242. coap请求
  243. coap响应
  244. 消息种类
  245. 延迟响应(delayed response)
  246. 多播消息(multicast message)
  247. core link format
  248. 结论:非http协议的rest
  249. 附录a 状态法典
  250. 附录b http报头法典
  251. 附录c 为api设计者准备的fielding论文导读
  252. 词汇表
书名:RESTful Web APIs中文版
译者:赵震一, 李哲 译
国内出版社:电子工业出版社
出版时间:2014年05月
页数:382
书号:978-1449358068
原版书书名:RESTful Web APIs
原版书出版商:O'Reilly Media
Leonard Richardson
 
Leonard Richardson, 《Ruby Cookbook》 (O’Reilly)一书的作者,曾 创建了包括Beautiful Soup在内 的多个开源代码库。
 
 
Mike Amundsen
 
Mike Amundsen是API学院的首席 架构师,负责帮助各个公司发展 API业务。
Mike Amundsen 是包括《Building Hypermedia APIs with HTML5 and Node》(O’Reilly) 在内的十几本为人所称道的技术图书的作者。
 
 
购买选项
定价:79.00元
书号:978-1449358068
出版社:电子工业出版社