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》覆盖了当今api领域最重要的趋势和实践。”
——john musser programmableweb创始人
]
本书特色
[
《restful web apis中文版》是针对restful api的实用指南，通过展示各种用来创建高可用应用的强大工具，讲解rest的深层原理，以及介绍基于超媒体api的策略，使读者得以在将上述内容融会贯通后，设计出让客户高度满意的restful的web api。《restful web apis中文版》极具权威性与前瞻性，既代表了api领域的*前沿趋势，也覆盖了api领域的*重要实践。
《restful web apis中文版》适合所有从事web开发和架构工作的读者阅读参考。
]
作者简介
[
Leonard Richardson， 《Ruby Cookbook》 （O’Reilly）一书的作者，曾 创建了包括Beautiful Soup在内 的多个开源代码库。Mike Amundsen 是包括《Building Hypermedia APIs with HTML5 and Node》（O’Reilly） 在内的十几本为人所称道的技术图书的作者。
Sam Ruby 是W3C HTML工作组的联合主席，同时也是IBM新 兴技术组的一名高级技术人员。
]
目录
序 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 论文导读词汇表
封面
书名:RESTful Web APIs中文版
作者:理查德森
页数:382
定价:¥79.0
出版社:电子工业出版社
出版日期:2014-06-01
ISBN:9787121231155
PDF电子书大小:114MB 高清扫描完整版