作者：曾著,徐必涛
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
RESTfulWebClients：基于超媒体的可复用客户端试读：
前言
中，Sam Ruby说道：希望RESTful Web APIs这颗鹅卵石可以像它的先驱RESTful Web Services那样具有影响力。但谁也说不好，也许七年之后这一切又将重演，从而强调表述性状态迁移（Representational State Transfer）仍然没有受到应有重视的方面。
现在虽不是此前的七年之约，但RESTful Web Clients已经如期而至。Mike在API领域精耕细作多年，通过本书的文字，我们可以领略他在写作和思想上一贯清晰的风格，以及那部分被忽略的Web API。
REST一词出自Roy Fielding的博士论文《架构风格与基于网络应用软件的架构设计》。在论文的前面部分，Fielding介绍了用于描述REST的七个基本架构约束，第一个是客户-服务器（Client-Server，CS），其中描述如下：
分离关注点是在客户端-服务器约束背后的原则。功能的适当分离会简化服务器组件，从而提高可伸缩性。这种简化所采用的形式通常是将所有的用户界面功能（user interface functionality）移到客户组件中。只要通信的接口不发生改变，这种分离允许两种类型的组件独立地进化。
显然，通过这种方式设计系统时，服务端和客户端同等重要。然而，那些基于Fielding论文所完成的工作中普遍存在一种偏见：几乎所有的工作都聚焦在服务端，却很少讨论客户端。这样便遗漏了一个非常重要的部分，RESTful架构的一些好处只能通过良好设计的客户端来实现了。虽然有许多客户端-服务器架构风格的系统，但都没有遵循Web中的一些原则。如果我们必须采取某种方式让服务端更接近Web的运行方式，那么我们也必须改变客户端的编写方式。
事实上，在我们构建Web API时，这是向Web思维方式转变的一个难点所在。对此，我与热衷于部署超媒体技术的组织有过诸多讨论，他们不懈地将这些努力付诸实践。我相信这其中的很多困难都来自超媒体的生产，因为并没有考虑到API消费方式的变化。如果当API设计人员期望构建一个Web API客户端时，可以采用消费其他API的原则来消费RESTful API，那么结果将会令人沮丧。不过，这一切都是可以理解的，毕竟那些倡导这种架构风格的人员几乎都集中在API的生产方。
事后来看，这种缺陷其实很明显：如果我们只关注方程的一边，我们该如何设计一个好的系统呢？我确信这种情况是现如今人们对API认识所导致的一个二次效应：我的组织关注的是如何为我的产品提供一个API，但使用这个API的是你的组织，所以如何处理它是你分内的事。过去的五到十年中，这种关于API的潜在情绪有所扩大：转向“简单的API，我们不需要复杂的SDK来完成工作”。同时，提供API客户端的组织也常常被投以怀疑的目光。不过，我们现在可以看到事情已经开始反转，开发人员已经厌倦每次为新的API重新部署一次客户端。官方提供的SDK正被逐渐正视，通过这些SDK， API的消费者可以更多地将关注点放在自己的应用上，而不是API的集成上。
此外，Web也越来越被看作是应用平台，而不是用于分享文本文档的一种简单方式。随着专属平台的兴起，特别是在移动领域，那些热爱Web自由和开放的人们，正在动员更多的人来显著扩展Web平台的能力。为了利用这一优势，随着他们的产品愈发雄心勃勃，应用也随之萌芽了越来越多的JavaScript代码。而这些应用正是另外一种客户端，随着时间的推移，它们也将日趋重要。
随着格局的转变，组织需要再次考虑方程两边的平衡问题。从广义上讲，我认为这会产生更好的API，但它们不会都是“玫瑰”。正如我之前所提到的，你可以买到无数的书籍来帮助你了解方程的服务端一边，但是在客户端方面却完全没有一个类似的指导手册——至今仍是如此。
自从Mike告诉我他开始着手这一工作以来，我一直在期待着这本书，而他也确实没有让我失望。对于Web API方程式中缺失的那部分，本书堪称一部梦幻般的指南，我相信它的作用和影响在未来数年内将得到关注。希望你也可以像我一样享受这本书的阅读过程。——Steve Klabnik前言
开始阶段是工作中最重要的部分。——柏拉图（Plato）
基于Web的REST和超媒体服务正日趋普遍，但却鲜有客户端可以利用这些API的强大功能。这主要是因为缺乏创建成功的超媒体客户端的技术和模式——长期以来它们一直被忽视。然而，如果可以采取恰当的方式，基于超媒体的客户端应用将会比典型的一次性客户端具有更强的稳定性和灵活性。
本书旨在为读者提供一个坚实的背景知识和一些可工作的示例源码，这些示例为如何处理超媒体API提供了明确的建议。本书的主要思想之一是客户端应用程序应该依赖于Request、Parse和Wait所构成的循环，我简称其为RPW循环。这是所有电脑游戏采用的实现方式，也是所有事件驱动接口从窗口式工作站（windowing-style workstation）到响应式机器接口（reactive machine interface）的工作方式。
有人告诉我，一些前端的开发人员可能会认为RPW模式比较生僻，甚至也有人认为我的建议比较“激进”。对于这些观点，我都能理解。当下，众多的前端开发库和实践都在致力于设计用于专门构建的一次性用户界面，这些界面难以修改，并且很难在运行时对服务提供的新信息做出反应。不过，在阅读本书的例子后，我希望前端开发人员（他们中的大多数都比我的经验更丰富）能够在目前初步工作的基础上创造出更丰富的最佳实践、工具和可重用的库，为越来越多的超媒体API打造高质量的用户体验，力争在不需要频繁升级的情况下满足高质量的用户体验需求，以及不断发展的服务接口自适应客户端的需求。
本书讲了什么
本书将带领读者开启一段从个性化定制实现到强大的通用客户端应用的旅程，同时向你展示如何利用那些支撑万维网良好运行的基本原则。本书包括以代码为中心的章节信息和对相关重要主题的探索，比如表述器模式、人机交互模型和Web API在版本控制上的挑战等。当然，其中也少不了大量的代码（我为本书创建了20多个GitHub仓库），包括一些小的代码片段。不过，这些片段单独看可能不易理解。因此，我会为读者指出完整的在线代码库的位置，你可以在相关代码库中找到本书所涵盖的全部功能实例。
各章内容
本书探讨了通用超媒体风格客户端的世界，包括它们的外观、与典型JSON对象客户端的区别，以及客户端和服务端开发者如何构建更易于支持和适应的系统。本书包含了一些专项讨论所选格式（如HTML、纯JSON、HAL、Siren和Collection+JSON）的章节，以及所有Web开发人员需要熟悉的理论和实践的章节，包括服务端对消息格式的支持、人机交互模型、版本控制，以及一个在同时与多个独立的后端服务进行交互时可以支持多种超媒体格式的解决方案。
本书的大多数章节都可以独立成章，在阅读时可以不讲究先后顺序。不过，为了更充分地理解和吸收本书的内容，我鼓励你将本书看成一次单程旅行，按照顺序从头读到尾。这里简单介绍一下本次旅程的路径。
第1章，从HTML到简单Web API
本章向我们介绍了一个经典的纯HTML客户端。我们将通过它来了解浏览器的基本工作原理，以及它们是如何影响人们看待Web中那些超媒体格式的。此外，本章还介绍了将纯HTML服务转换为一个原始的纯JSON服务的过程。该服务将是我们为本书构建的所有其他客户端应用程序的基础。
第2章，JSON客户端
大多数的客户端Web开发人员都会构建JSON客户端，它会记住所有的URL，处理静态对象，并通过固定的工作路径来导航。构建JSON客户端是一个很好的开始，不过时间却证明它是一个糟糕的工作方式。在本章中，我们将讨论如何克服在维护纯JSON风格客户端应用程序时的挑战。
第3章，表述器模式
表述器模式是处理服务器输出的一种简单而重要的方式，也是将内部对象模型转换为外部消息模型的过程。我们将在本章中审视该模式（及其源头），并介绍如何使用服务器上的Web服务迁移语言（WeSTL）和浏览器客户端上的HTML DOM将该模式应用于API提供方。
第4章，HAL客户端
HAL媒体类型是目前较为流行的超媒体格式之一。比如在Amazon的Web服务团队中，至少有两个API使用了HAL。对于所有Web客户端都需要处理的三个重要元素， HAL负责处理其中之一： ADDRESS挑战。我们将看到如何将HAL作为消息格式来构建一个通用客户端，以及如何通过HAL-FORMS扩展来提高HAL的处理能力。
第5章，可重用客户端应用的挑战
你会注意到，我们所构建的多数客户端看起来都很类似。从本质上讲，我们正在建立能够在探索周围世界（以某种有限的方式）的过程中发展自己的“探险者”。这些客户端都采用了Request—Parse—Wait循环，即RPW模式。该模式基于我们如何与世界交互这一命题下的几个经典概念，我们将在本章中探讨它们。
第6章，Siren客户端
Siren内容类型是另一种强大的超媒体类型。Siren目前被用作Zetta IoT平台的一部分，旨在处理Web客户端的三个关键任务中的两个：ADDRESS和ACTION。我们将看到使用Siren作为消息格式来构建一个通用客户端，也会通过探索Siren拓展（Profile for Object Display，即POD）来增强它在UI上显示元数据的能力。
第7章，版本化与Web
当你开始将超媒体类型作为客户端Web应用程序的基础时，API版本的概念会发生什么变化？本章将讨论管理随时间变化的各种尝试，以及如何依赖基于消息的超媒体风格的API来减少当接口特性发生变更时也要变更接口契约的问题。
第8章，Collection+JSON客户端
在本章中我们将探讨另外一种超媒体格式：Collection+JSON，或称为Cj。Cj能够处理Web客户端中的所有元素：OBJECT、ADDRESS和ACTION。我们将看到如何将Collection+JSON作为消息格式来构建一个通用客户端，并学习如何扩展Cj的数据显示和验证程序。
第9章，超媒体与微服务
创建一个可以无缝调用多个服务的通用超媒体客户端需要什么？如果这些服务使用的超媒体类型各不相同，又需要什么呢？当我们谈论消息格式时，该怎样制作一个可以“说”多种语言的客户端应用？这一切将在最后一章中揭晓。
对话
本书的所有章节都以简短的小插曲或对话开始和结束。我们通过这些虚构的对话来说明，组织在思考如何在互联网上创建可扩展且稳定的项目时所遇到的挑战。这些对话既是各章主题的铺垫，也是主题的
总结
。此外，对话也是一种提示，让读者有机会思考所提出的挑战，以及如何应对这些挑战并给出解决方案。每章从对话开始读起，读完后花几分钟时间来描绘（也可以写下来）一下你对于如何解决问题的想法。这种方式可以帮助你对书中提供的解决方案形成更深刻的认识，并对自己的问题解决能力有额外的洞察。
最后，这些对话还可以帮助那些只想跳跃阅读书中部分内容的读者收获一些感悟。你可以单独阅读对话，并收集相关的基础信息。各章内容也正是对对话中的细节和微妙之处进行了深入讨论。你可能会发现，至少在某些章节中，阅读对话可以获取当前主题或挑战相关的所有信息，而且还很不错。
艺术作品
本书包含了一些才华横溢之辈的艺术作品和图表。Dana Amundsen，路易斯维尔（Louisville） KY的一位成功的艺术家，和我一起创作了本书中出现的人物Bob和Carol。此外，她还设计了示例程序中所使用的BigCo徽标。事实上，Dana创作的作品比本书所包含的要多得多，希望在不久的将来可以通过其他方式将这些艺术作品分享出去。
本书中的图表均由我的好友Diogo Lucas创作，他是一位资深的软件工程师、架构师、演说家和老师。我第一次遇见Diogo是在前往巴西（他的居住地）的旅途中，当谈论关于本书的一些想法时，他向我展示了令人惊叹的草图。我抓住这个机会邀请他创作插图，很幸运，Diogo欣然同意贡献他的艺术才华。
本书所使用的Dana和Diogo的艺术作品，均是根据Creative Commons - Attribution-NoDerivatives 4.0 International(CC BY-ND 4.0)获得授权的。
Dana和Diogo为本书增加了很特别的内容，我非常感谢他们。
本书没有讲什么
本书在相对有限的篇幅中涵盖了较广的内容范围。为了做到这一点，我需要删减一些有用的素材。接下来简单介绍一下那些没有涵盖在本书中的内容。
用户界面设计
虽然我在本书中提到了关于用户界面设计的一些资料，但它们都是比较粗略的。而且通常情况下，我不会花费时间来了解人机交互（HCI）或设计方法的细节。
我也要提醒一下读者，本书示例中所提供的都是基本的UI。我主要的关注点是网络和消息层面的技术，即允许服务向客户端应用程序提供可识别和有用的超媒体提示。在客户端解析和激活这些超媒体信息的最佳实践方面，我也付出了时间。而关于界面修饰和视觉吸引力改进方面的工作则不是本书的重点（如需了解，请关注这方面的专业人士）。
特别感谢Benjamin Young
我要特别感谢我的老朋友、资深的Web开发人士Benjamin Young。他一遍又一遍地检查了我的基本UI设计，并为所有的客户端应用程序提供了一致的外观。说实话，我给Benjamin的创作空间是有限的，但他仍然针对所有应用设计了稳重而一致的风格指南。如果它们看起来都很赏心悦目，那正反映了Benjamin的才华和坚持；如果它们在某些方面不符合标准，那是因为我并没有给Benjamin所需要的自由。
超媒体基础
这本书不会花费太多篇幅来讨论将超媒体作为实现风格时的价值收益，也不会深入讲解如何在你自己的项目中使用超媒体创建一个具体的例子。关于超媒体Web API的历史和价值基础，我此前的作品RESTful Web APIs（和Leonard Richardson合著，中文版为《RESTful Web API中文版》）以及Building Hypermedia APIs with HTML5 and Node（中文版为《使用HTML5和Node构建超媒体API》）都是更好的
参考资料
。所以，关于这方面的信息，我建议读者阅读这两本书或其他资料。用HTML、CSS和JavaScript编程
最后，本书也没有涉及Web的编程基础，例如HTTP协议、HTML5、JavaScript和CSS等方面。这些都是非常重要的主题，但是这远远超出了这本小书要讨论的范围。这些主题有很多相关的书籍，我相信读者可以方便地找到。
源代码
这本书涉及相当多的源代码。几乎每章都有一个工程项目，有的甚至有两个或更多个。如果将这些源码都放在书里，那将导致阅读和浏览很不方便。因此，本书中出现的都是一些非常重要而简短的代码片段。
完整的源代码可以在GitHub的公有仓库（https://github.com/rwcbook）中获得。这些资料将会不定期地更新，所以它是本书中所有源代码片段的最准确的来源。建议读者clone或fork这些源代码，对于必要的变更，也欢迎提交pull request。
外部参考
在整本书中，我引用了很多外部资料和参考文献，包括其他书籍、发表的论文、文章、公共标准和博文。我会在书中提到相关的参考资料，但不是以直接引用或者脚注的形式，因为这会影响阅读的流畅性。我会在每个章的末尾增加一个部分，列出参考资料的名称和相关的链接。
本书所使用的约定
以下是本书所使用的排版约定。
中文楷体或英文斜体（Italic）
表示新的术语、URL、邮件地址、文件名称和文件拓展名。
等宽字体（Constant width）
表示程序片段，也可以用在正文中表示变量名或函数名等程序元素、数据类型、环境变量、语句和关键词等。
等宽字体加粗（Constant width bold）
表示应该由用户输入的命令或其他文本。
等宽字体加斜（Constant width italic）
表示应当被用户自定义的值或上下文决定的值所替换的文本。
这个图标表示提示或建议。
这个图标表示一般的说明。
这个图标表示警告或注意。
O’Reilly Safari
Safari（以前的Safari Books Online）是企业、政府、教育者和个人的会员制培训及参考平台。
订阅者可以从一个完全可搜索的数据库中获得来自250 多家出版商提供的成千上万的书籍、培训视频、互动教程，这些出版商包括O’Reilly Media、Harvard Business Review、Prentice Hall Professional、Addison-Wesley Professional、Microsoft Press、Sams、Que、Peachpit Press、Adobe、Focal Press、Cisco Press、John Wiley&Sons、Syngress、Mor-gan Kaufmann、IBM Redbooks、Packt、Adobe Press、FT Press、Apress、Manning、New Riders、McGraw-Hill、Jones&Bartlett和Course Technology。
若想获得更多资讯，请访问http://oreilly.com/safari。
联系我们
请将对本书的评价和发现的问题通过如下地址通知出版社。
美国：
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035）
奥莱利技术咨询（北京）有限公司
我们提供了本书网页，上面列出了勘误表、示例和其他信息。请通过http://bit.ly/restful-Web-clients 访问该页。
要给出本书意见或者询问技术问题，请发送邮件到bookquestions@oreilly.com。
更多有关书籍、课程、会议和新闻的信息，请见网站http://www.oreilly.com。
在Facebook找到我们：http://facebook.com/oreilly。
在Twitter上关注我们：http://twitter.com/oreillymedia。
在YouTube上观看：http://www.youtube.com/oreillymedia。
致谢
这本书的出版离不开很多人的倾情奉献和帮助。我特别感谢那些自愿阅读和评论本书早期草稿的读者，尤其是Todd Brackley、Carles Jove i Buxeda、Pedro Felix、Mark Foster、Toru Kawamura、Mike Kelly、Steve Klablnik、Ronnie Mitra、Erik Mogensen、Irakli Nadareishvili、Leonard Richardson、Kevin Swiber、Stefan Tilkov、Ruben Verborgh和Jeremy Wilken，他们在本书的创作过程中提供了宝贵的反馈和建议。
我还要感谢O’Reilly团队的所有支持和信任，特别是Simon Foley和Simon St.Laurent在漫长的创作过程中给我的源源不断的鼓励。此外，感谢我的出版编辑Colleen Lobner，在她将我的文字整理出版的过程中，不得不忍受我无尽的细微布局和字体问题。我也特别感谢API学院和CA Technologies的同事在整个项目中所提供的帮助和支持。
最后，我要再一次感谢我的家人。当我着手处理问题、戴上耳机进行长时间思考，以及当我陷入细节和测试场景的沉思时，你们用耐心和幽默包容着我。谢谢你们。
读者服务
轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。
● 提交勘误：您对书中内容的修改意见可在 提交勘误 处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
● 交流互动：在页面下方 读者评论 处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http://www.broadview.com.cn/33758
开场：嗯，那是一次有趣的旅行，不是吗
“实践是学习的最好途径。”——Shannon Kaiser，50 Things My Future Self Wants Me To Know参考资料
1.Shannon Kaiser 的引言摘自她于2014年9月在MindBodyGreen（http://mindbodygreen.com）上发表的一篇文章（http://g.mamund.com/ewvgz）。
Bob、Carol和BigCo公司
BigCo公司是一个成功的跨国公司，本书的所有各章都以这个公司IT部门的两位同事的简短对话作为开始和结束，这两位同事就是Bob和Carol，他们都是老练的、训练有素的软件专家。这里介绍一下公司和两位同事的背景，以便你更好地理解他们的对话。
BigCo公司
具有繁荣悠久历史的贝叶斯国际集团公司（BigCo）于1927年在苏格兰创建。它的座右铭是“让顾客和雇员满意是我们的宗旨”。公司最初是在Richard Price工作的基础上专注于人工统计学和金融。20世纪初，通过与设备发明者Frederick Jones和ReginalFessenden分别合作，BigCo开始生产包括移动x射线设备和水听器等在内的重要设备，成为世纪之交的重要技术的制造商。BigCo还是为数不多的曼哈顿计划的非美国合同商之一，为Leona Wood博士设计的第一个核反应堆提供部件。
在战后繁荣期间，BigCo在美国建立了办公室，帮助开启了现代计算机时代的多个研究领域并发挥了积极的作用，其中包括预测算法和机器人控制。当下，BigCo产品聚焦于“逆概率”问题，以及如何用“逆概率”改善私人和公共领域的决策和政策制定。
Carol
Carol这几年在BigCo公司领导了几个成功的团队。在此之前，她写了五年的桌面系统和Web系统代码，拿到了计算机科学与信息系统的双学位，并活跃在多个知名的开源社区。Carol还是一个技艺高超的视觉艺术家，是本地艺术社团的一员。除了写开源软件，或在家和她的两只猫咪休闲玩耍， Carol还会参加地区漫画大会，在那儿出售她的作品，找到漫画社区的同好们。
Bob
Bob最近从一个硅谷新创合并公司跳槽到了BigCo公司。他曾经创立过多个基于Web的公司（其中一个是在上大学时创立的），他告诉人们自己有“创业病”。在他出售第一个公司获益颇丰之后，Bob抽时间完成了他的计算机学士学位，随即又返身投入创业。他把仅有的一点闲暇时间都用来在附近的州立公园和国家森林里攀岩和骑自行车。每年他都会数次前往落基山脉和大瀑布附近，和朋友一起进行危险的阿尔卑斯山式攀岩。
参与者
● 感谢Dana Amundsen（@DanaAmundsen）为本书设计图像和logo。
● 虽然BigCo是一个虚构的公司，但其描述中提及的所有人（Price、Jones、Fessenden和Woods）都是真实的历史人物。如果BigCo真的存在，这些人也会是BigCo历史的一部分。第1章从HTML到简单Web API“生活的迷人、沮丧和伟大之处在于，你可以不断地重新开始。我热爱这样的生活。”——Billy Crystal
我们不必急于着手创建超媒体应用客户端，先来回顾一下过往的历史，探索一下Web应用早期的往事。许多Web应用以网站起家，而这些基于HTML的页面其实和静态文档列表差别不大。在某些情况下，最初的Web应用是纯粹的HTML应用，包含一些数据表格、一些用于过滤和添加数据的表单，以及很多允许用户从一个页面跳到另外一个页面的链接（见图1-1）。图1-1 BigCo TPS界面截图
纯HTML应用很有意思，它用一种声明式的风格写成，不需要在客户端里写命令式的程序代码也可以工作。事实上，HTML应用的视觉风格也是声明式处理的——通过层叠样式表（CSS）。
试图只用声明式标记语言来营造用户体验，也许看起来并不常见，但应当注意到，Web初期的许多用户已经很熟悉主机（mainframe）世界的交互风格（见图1-2）。很多情况下，早期的Web应用看起来、用起来都类似于典型的黑白色体验，非常像主机、小型机和早期PC的用户体验（见图1-3），这种相似被看作是一件好事。图1-2 IBM兼容PC
通常，对于一个成功的HTML应用来说，在其生命周期的某个时刻，总会有人试图将它转变成一个Web API。产生这一动机的原因有很多：也许是想释放被锁定在单一应用中的价值，以便将表层下的功能提供给更广泛的用户；也许是在其他的UI平台（例如移动设备、富桌面应用，等等）上出现了新的机会，但这些UI平台并不支持HTML+CSS的体验；也许是有人想到一个创新的主意，想把它付诸实践。总之，无论出于怎样的缘由，一个Web API诞生了。图1-3 早期的Lynx HTML浏览器
这一过程通常是直截了当的：只需要丢弃现有的HTML UI的包袱，然后将现存Web应用涵盖的内部功能暴露为API即可。确实，最初的工作正是如此——移除UI（HTML），并将Web服务器代码中的数据模型或对象模型暴露为想要的这个Web API。
接着，假定新的团队可以通过从客户端应用直接消费服务端的Web API来构建更好的用户界面，其目标常常是为智能手机构建本地应用，或者用最新的客户端框架构建一个高级Web应用。一开始API相当容易理解，构建一套客户端应用也非常顺利，尤其当客户端和服务端内部代码是由同一个团队，或两个对原Web应用有着相同且深刻理解的团队构建时更是如此。
这就是本章我们将要学习的内容——从HTML到API，这将为本书后续的部分打下基础。在后续章节中，我们将在超媒体的原则和实践的指导下，完成一个健壮的、可适配的客户端应用的增量创建过程。任务处理系统（TPS）Web应用
快速回顾一下，Carol的团队构建了一个Web应用，从Web服务器直接向通用Web浏览器发布HTML（和CSS）。这个应用能够在所有品牌和版本的浏览器运行（没有CSS戏法，所有的HTML都是标准的，也完全没有JavaScript）。TPS应用在第一次设计和实现时，团队便定义了最初的关键用例。通过聚焦这些关键用例，应用将会运行得很流畅，而相应的工作也会如期完成。
应用的UI如图1-4所示，虽然看起来不会赢得任何奖项，但它能用、实用、可靠——这是我们想在任何应用中看到的品质。图1-4 TPS用户界面
在关联的GitHub仓库（https://github.com/RWCBook/html-only）中可以找到TPS这个版本的代码。本章应用（App）的一个可运行版本可以在线上找到（http://rwcbook01.herokuapp.com）。来自服务器的HTML
TPS应用成功的原因之一是它非常简单。Web服务器送出干净的HTML，这个HTML包含完成用例需要的所有链接和表单：＜ul＞＜li class="item"＞＜a href="https://rwcbook01.herokuapp.com/home/" rel="home"＞Home＜/a＞＜/li＞＜li class="item"＞＜a href="https://rwcbook01.herokuapp.com/task/" rel="collection"＞Tasks＜/a＞＜/li＞＜li class="item"＞＜a href="https://rwcbook01.herokuapp.com/user/" rel="collection"＞Users＜/a＞＜/li＞＜/ul＞
例如，在前面列出的代码中，你可以看到HTML锚点标签（...），它指向一个当前页面关联的内容。这套“菜单链接”出现在TPS应用送出的每一个页面的顶端：＜div id="items"＞＜div＞＜a href="https://rwcbook01.herokuapp.com/user/alice"rel="item" title="Detail"＞Detail＜/a＞ ❶＜a href="https://rwcbook01.herokuapp.com/user/pass/alice"rel="edit" title="Change Password"＞Change Password＜/a＞ ❷＜a href="https://rwcbook01.herokuapp.com/task/？assignedUser=alice"rel="collection" title="Assigned Tasks"＞Assigned Tasks＜/a＞ ❸＜/div＞＜table＞❹＜tr＞＜th＞id＜/th＞＜td＞alice＜/td＞＜/tr＞＜tr＞＜th＞nick＜/th＞＜td＞alice＜/td＞＜/tr＞＜tr＞＜th＞password＜/th＞＜td＞a1!c#＜/td＞＜/tr＞＜tr＞＜th＞name＜/th＞＜td＞Alice Teddington, Sr.＜/td＞＜/tr＞＜/table＞＜/div＞
服务器渲染的列表中的每一个用户包含指向单个用户记录的链接（❶）、一些数据字段（❹）和一些指向这个用户可以执行的其他动作（❷和❸）的链接。 以下这些链接允许任何人查看发起更新或密码修改的页面（假设他们有权限执行这些操作）：＜!-- 添加用户的表单 --＞＜form method="post" action="https://rwcbook01.herokuapp.com/user/"＞＜div＞Add User＜/div＞＜p＞＜label＞Nickname＜/label＞＜input type="text" name="nick" value=""required="true" pattern="[a-zA-Z0-9]+" /＞＜/p＞＜p＞＜label＞Full Name＜/label＞＜input type="text" name="name" value="" required="true" /＞36 | Chapter 1: Our HTML Roots and Simple Web APIs＜/p＞＜p＞＜label＞Password＜/label＞＜input type="text" name="password" value=""required="true" pattern="[a-zA-Z0-9!@#$%^&*-]+" /＞＜/p＞＜input type="submit"/＞＜/form＞
添加用户的HTML也非常简单（见上述HTML），这是一个干净的HTML＜form＞，跟着关联的＜label＞和＜input＞元素。事实上这个Web应用的所有输入表单都长得差不多。每一个用于查询操作（安全操作）的＜form＞都有一个设置为get的method属性，每一个用于写操作（不安全的操作）的＜form＞都有一个设置为post的method属性。对于这个实现来说，这是＜form＞设置的唯一重要区别。
有关HTML和POST的备注
在HTTP里，POST方法定义了一个非幂等的、不安全的操作（RFC7231）。TPS Web应用里的一些动作可以被一个幂等而不安全的操作处理，但HTML （仍然）不支持PUT或DELETE操作（HTTP里两个幂等而不安全的操作）。Roy Fielding在2009年的一篇博客（http://g.mamund.com/sstuc）中指出，在Web上只用GET和POST当然可能完成所有事情，但如果一些操作是幂等的，事情会变得更容易一点，因为这样使得处理回复失败的请求更容易。截至本书写作时，将PUT和DELETE操作置入HTML的某些努力仍然在遭受冷遇。
除了典型的列举、读取、添加、更改和移除等操作，TPS Web应用还包括一些其他操作，例如更改用户密码、给任务指派用户。下面就是驱动指派用户界面的HTML（图1-5展示了这个界面）：＜!-- 分配用户的表单 --＞＜form method="post" action="//rwcbook01.herokuapp.com/task/assign/137h96l7mpv"＞＜div＞Assign User＜/div＞＜p＞＜label＞ID＜/label＞＜input type="text" name="id" value="137h96l7mpv"
readonly="readonly" /＞＜/p＞＜p＞＜label＞User Nickname＜/label＞＜select name="assignedUser"＞＜option value=""＞SELECT＜/option＞＜option value="alice"＞alice＜/option＞＜option value="bob" selected="selected"＞bob＜/option＞＜option value="carol"＞carol＜/option＞＜option value="mamund"＞mamund＜/option＞
试读结束[说明：试读内容隐藏了图片]