作者：丁雪丰,常可
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
RESTful Web Services Cookbook中文版试读：
前言
2000年，HTTP和URI的关键贡献者Roy Fielding在题为“Architectural Styles and the Design of Network-Based Software [1]Architectures”的博士论文中精确地阐述了Web的架构。在这篇论[2]文中，他引入了一种名为表述性状态转移（Representational State Transfer,REST）的架构风格。抽象地说，这种风格描述了World Wide Web的基础，其组成技术包括Hypertext Transfer Protocol（HTTP）、Uniform Resource Identifier（URI）、类似HTML和XML的标记语言以及类似JSON这样的适用于Web的格式。
REST是一种面向网络化应用程序的架构风格，其中包含了很多用于描述分离关注点、可见性、可靠性、可扩展性、性能等诸多方面的约束。附录 B 是对这些约束的一个简单概述。Web的基础设施使得开发者倾向于用REST来构建分布式的、去中心化的客户端/服务器应用程序。在这些基础设施上部署 Web 服务让你可以利用众多已有的基础设施，其中包括Web服务器、客户端库、代理服务器、缓存、防火墙等。尽管从理论上来说，能够脱离HTTP来构建RESTful的应用程序，但这样做的代价很大。在本书中，RESTful Web服务指的是通过HTTP,URI,XML,JSON和Atom等技术构建的Web服务。
本书范围
本书并非针对REST的论文，也不是在描述它相对于其他架构风格的优点，而是为RESTful Web服务的设计者和开发者提供的一本指南。
目前已经有大量描述 REST 架构风格的材料了。Wikipedia 关于表述性状态转移的条目（http://en.wikipedia.org/wiki/Representational_State_Transfer）中提供了REST基础概念的精确描述、约束、设计应用程序的指导原则。Leonard Richardson和Sam [3]Ruby的“RESTful Web Services”（O'Reilly）更深入地探讨了这个主题，详细讲述了如何将资源用做核心构建部件。但在日常的设计与实现中遇到了问题该如何获取帮助呢？本书就是来弥补这个空缺的。
本书由多个用于帮助设计及实现 RESTful 客户端/服务器应用程序的技巧组成，无论你的Web服务是否是RESTful的，它们都能帮你利用好Web基础设施和REST。每个小节都包含一个或多个问题描述和一个解决方案，随后的详细讨论中有例子、关于实现的讨论和所涉及的各种权衡考虑。
书中的多数材料都基于开发RESTful Web服务时遇到的常见设计问题，包括HTTP使用、资源和表述设计、URI、缓存、并发控制、部分更新（partial updates）、批处理、事务、安全、版本控制、兼容性等内容。
本书并不特定于某种编程语言，其中使用HTTP请求和响应消息来说明实现。你可以用C#,C++,Java,Ruby,Python,PHP和Perl这样的语言来进行实现。附录A里有一个针对特定语言的图书列表，你也可以去你喜欢的书店找找。
本书也不涉及安装、管理或保护Web服务器、缓存及代理。可以[4]参考Ken Coar和Rich Bowen 4的“Apache Cookbook”、Ivan Ristic的“Apache Security”和Duane Wessels的“Squid: The Definitive [5]Guide”（全由O'Reilly出版），或者产品手册来了解相关主题。
辅助材料
访问http://www.restful-webservices-cookbook.org可获得关于本书的附加材料、勘误、评论与问题。
下面这些资源十分有用：
REST-Discuss Yahoo! Group（http://tech.groups.yahoo.com/group/rest-discuss）
如果你有REST架构风格相关的问题，可以检索该讨论组的存档。更好的做法是加入讨论组，发表你的问题，参与有关REST优缺点、常见问题和针对RESTful Web服务的HTTP用法的讨论。
Leonard Richardson和Sam Ruby的“RESTful Web Services”（O'Reilly）
阅读此书可更多地了解REST以及如何使用Web作为构建RESTful Web服务的平台。
RESTwiki（http://rest.blueoxen.net/cgi-bin/wiki.pl）
该Wiki中收录了多年来编写的描述REST多个方面及其应用程序的文章。
Chris Shiflett的“HTTP Developer's Handbook”（Sams）
如果你在客户端或服务器端应用程序中使用HTTP时遇到问题，可以阅读此书。
毫无疑问，会有本书以及之前讨论到的资源中没有涵盖到的设计与实现问题，请访问http://www.restful-webservices-cookbook.org发表你的问题、建议或者是你成功实施过的其他解决方案。在适当的时候，该站点将包含更多技巧，并且它们将被收入本书的下一个修订版中。
本书内容
如下所示，本书分为14个章节和5个附录：
第1章，使用统一接口
本章描述了使用HTTP统一接口以及处理诸如无状态、可见性、安全性和幂等性、可扩展性、创建新资源、GET还是 POST等问题的细节。本章的内容主要关注于使用 HTTP的统一接口。
第2章，识别资源
本章描述了如何识别资源以涵盖常见应用场合。
第3章，设计表述
本章描述了如何设计表述，如何使用请求和响应的HTTP标头，如何选择媒体类型和格式，以及如何进行错误处理。
第4章，设计URI
本章描述了设计URI、将URI作为标识符和保持良好URI的常见方法。
第5章，Web链接
本章展示了何时应该在表述中使用链接，如何使用，还涉及表述正文中链接的详细情况、链接头、URI模板和链接的应用。
第6章，Atom和AtomPub
本章介绍了如何使用 Atom Feed、Entry、媒体资源以及将文档作为资源；如何使用AtomPub协议；何时使用Atom来设计资源表述。
第7章，内容协商
本章展示了如何基于媒体类型、字符编码、内容编码或内容语言来协商表述；如何使用Vary头；何时使用内容协商。
第8章，查询
本章展示了一些针对查询设计URI、处理大查询和存储查询的方法。
第9章，Web缓存
本章描述了如何在服务器上支持过期缓存以及如何在客户端处理缓存。
第10章，条件请求（Conditional Requests）
本章描述了如何在服务器与客户端针对多种HTTP方法实现条件请求，并展示了条件请求是如何帮助进行缓存、乐观并发控制和保证幂等性的。
第11章，其他内容
本章展示了如何解决那些初看超出REST和HTTP范畴的设计问题。其中的主题包括复制、合并、部分更新、批处理和事务。
第12章，安全
本章展示了如何满足常见安全需求，例如身份验证（authentication）、授权（authorization）、代理（delegation）等。
第13章，可扩展性与版本控制
本章展示了如何编写可扩展的服务器，如何让客户端对变化保持弹性，如何实现版本控制。
第14章，服务发现（Discovery）
本章描述了如何为RESTful Web服务编写文档。
附录A，辅助读物
这个附录中提供了一些资源，你能从中找到更多关于REST及其基础技术的信息。
附录B,REST概述
这个附录中提供了一个REST的简要介绍，并带有一个示例。
附录C,HTTP方法
这个附录中展示了如何使用标准HTTP方法。
附录D,Atom Syndication Format
这个附录中提供了一个关于Atom Feed和Entry文档的参考。
附录E，链接关系类型
这个附录中罗列了读者能在链接中使用的链接关系类型（link relation type）。
本书使用的约定
本书中使用如下排版约定：
斜体
表示新术语、URL、电子邮件地址、文件名及文件扩展名。
定宽字体
用于程序示例、在段落中引用程序元素，例如变量或函数名、数据库、数据类型、环境变量、语句及关键字。“#”开头的定宽字体
用于表示HTTP请求和响应消息中的注释。例如：此图标表示小贴士、建议或注意事项。此图标表示警告或提示。
中文版书中切口处的“”表示原书页码，便于读者与原英文版图书对照阅读，本书的索引所列页码为原英文版页码。
使用代码示例
本书是要帮助你完成任务。总的来说，用户可以在程序和文档中使用书中的代码，无须联系我们获得许可，除非是要复制大部分代码。举例来说，写个程序，其中使用了几段书中的代码，这无须获得许可。销售或分发O'Reilly图书的示例CD-ROM需要获得许可。在回答问题时引用本书及示例代码无须获得许可。在你自己的产品文档中使用大量本书的示例代码需要获得许可。
如果能标明出处，我们将十分感激，但这不是必需的。通常这包括标题、作者、出版社和ISBN。例如：“RESTful Web Services Cookbook by Subbu Allamaraju.Copyright 2010 Yahoo!,Inc.,978-0-596-80168-7。”
如果你觉得自己对示例代码的使用超出了正常使用范畴或不在此处给予的许可范围内，请通过permissions@oreilly.com联系我们。
Safari®在线图书Safari Books Online是一个按需索取的电子图书馆，让你能够轻松地在超过7500本技术及创新参考书和视频中进行检索，快速找到你需要的答案。
订阅之后，你可以在我们的在线图书馆中阅读图书并观看视频。在你的手机或移动设备上读书。在印刷前看到新标题，独家阅读撰写中的原稿，向作者进行反馈。复制粘贴代码示例，管理你的收藏，下载章节，在关键部分加上书签，添加笔记，打印页面，并从大量其他省时的特性中获益。
O'Reilly Media已将本书英文版上传至Safari Books Online。想访问本书或其他来自O'Reilly和其他出版商的类似主题，可以在（http://my.safaribooksonline.com）进行免费注册。
如何联系我们
请将对本书的评价和存在的问题通过如下地址告知出版者：
美国：
O'Reilly Media,Inc.
1005 Gravenstein Highway North
Sebastopol,CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
O'Reilly的每一本书都有专属网站，你可以在那找到关于本书的相关信息，包括勘误列表、示例代码以及其他的信息。本书的网站地址是：
http://www.oreilly.com/catalog/9780596801687/
或者：
http://www.restful-webservices-cookbook.org
对于本书的评论和技术性的问题，请发送电子邮件到：
bookquestions@oreilly.com
关于本书的更多信息、会议、资料中心和O'Reilly网络，请访问以下网站：
http://www.oreilly.com/
http://www.oreilly.com.cn/
致谢
本书得到了很多人的帮助。O'Reilly的Mary Treseler，作为本书的编辑，她通过提出正确的问题帮助完善了本书的大纲，还提供了很多必要的支持、鼓励和礼貌的劝说，这才让想法化为现实。
非常感谢Mark Nottingham和Hugo Haas帮我起草了本书大纲的初稿。
Mike Amundsen，他为本书贡献了部分内容，花费了大量时间，用了很多红笔逐行审阅本书并做了批注。他的那些改善本书质量的建议是无价的。尽管他很忙，但Mike总是随叫随到来讨论书中解决方案和真实世界里各种权衡的利弊。
感谢Havi Hoffman,Yahoo! Press的管理者，他很耐心地指导我编写提案，避免陷入精耕细作之中。感谢Neal Sample,James Lok,Jay Rossiter和Tony Ng（全来自Yahoo! Inc.）在本书的撰写过程中给予的支持。还要感谢Korby Parnell为本书的编写出谋划策。
我要衷心地感谢 Mark Nottingham,Eben Hewitt,Colin Jack,Stefan Tilkov,Norbert Lindenberg,Chris Westin,Dan Theurer,Shaunak Kashyap,Larry Cable,Alan Dean,Surya Suravarapu,Jim D'Ambrosia,Randolph Kahle,Dhananjay Nene和Brian Sletten，感谢他们对书中材料的明确性、相似性、质量和精确性提出有价值且具批判性的反馈。
感谢REST-Discuss Yahoo! Group（http://tech.groups.yahoo.com/group/rest-discuss）的成员，感谢他们对所有REST相关的内容进行的热烈、精彩且深刻的讨论。
还要感谢所有为本书草稿提出反馈的读者。
Mike Amundsen的贡献
Mike Amundsen贡献了4.1节、4.3节、6.1节、6.4节、9.1节、9.4节、9.5节、11.8节、11.9节、11.12节和附录D。[1]中文版标题为《架构风格与基于网络的软件架构设计》，由李锟、廖志刚、刘丹与杨光共同翻译，2007年6月发表于满江红翻译组网站（http://www.redsaga.com/opendoc/REST_cn.pdf）。[2]Representation在REST中有特殊含义，根据《架构风格与基于网络的软件架构设计》一文的翻译，本书将Representation翻译为“表述”或“表述形式”，将Representational翻译为“表述性”。[3]中文版书名为《RESTful Web Services中文版》，电子工业出版社出版。[4]中文版书名为《Apache Cookbook中文版》，电子工业出版社出版。[5]中文版在作者授权下由彭勇华翻译并发表在其个人网站中（http://home.arcor.de/pangj/squid/），标题为《Squid中文权威指南》。第1章使用统一接口[1]HTTP是一种应用层协议，它定义了客户端与服务器之间的转移 在此协议中，诸如 GET,POST,PUT和 DELETE之类的方法是对资源的操作。有了它，您就无须创造 createOrder,getStatus,updateStatus等应用程序特定的操作了。能从 HTTP基础设施中获得多少收益，主要取决于您把它当做应用层协议用得有多好。然而，包括 SOAP 和一些 Ajax Web 框架在内的不少技术都将 HTTP 作为一种传输信息的协议，这种用法很难充分利用 HTTP层的基础设施。本章包含以下内容，着重介绍了将 HTTP用做应用协议的几个方面：1.1节，“如何保持交互的可见性”可见性是 HTTP的关键特征之一，可通过本节了解如何保持可见性。1.2节，“何时需要权衡可见性”有时您可能需要对可见性进行权衡以满足应用的需要，可通过本节找到一些类似的场合。1.3节，“如何维护应用程序状态”通过本节了解管理状态的最佳方式。1.4节，“如何在服务器端实现安全和幂等的方法”保持安全性和幂等性有助于保证服务器能安全处理重复性请求。需要实现服务器时请使用本节的内容。1.5节，“如何在客户端处理安全和幂等方法”请按照本节的内容来实现客户端的安全性和幂等性原则。1.6节，“何时使用 GET方法”通过本节了解何时使用 GET方法。1.7节，“何时使用 POST方法”通过本节学习何时使用 POST方法。1.8节，“如何使用 POST方法创建资源”通过本节了解如何使用 POST方法创建新的资源。1.9节，“何时使用 PUT方法创建新资源”您可以使用 POST方法或 PUT方法创建新资源。本节将讨论什么情况下更适合使用 PUT方法。1.10节，“如何使用 POST方法实现异步任务”通过本节了解如何使用 POST方法实现异步任务。1.11节，“如何使用 DELETE方法实现异步删除”通过本节学习如何使用 DELETE方法实现异步的资源删除。1.12节，“何时使用自定义 HTTP方法”通过本节了解为什么不推荐使用自定义的 HTTP方法。1.13节，“何时及如何使用自定义 HTTP标头”通过本节了解何时及如何使用自定义 HTTP标头。1.1 如何保持交互的可见性
作为应用协议，HTTP 的设计目标是在客户端和服务器之间保持对库、服务器、代理、缓存和其他工具的可见性。可见性是 HTTP 的一个核心特征。按 Roy Fielding的定义（详见附录 A），可见性是“一个组件能够对其他两个组件之间的交互进行监视或仲裁的能力。”当协议是可见的时，缓存、代理、防火墙等组件就可以监视甚至参与其中。
问题描述
您想知道可见性的含义，以及如何保持 HTTP请求和响应的可见性。
解决方案
一旦您识别并设计资源，就可以使用 GET方法获取资源的表述，使用 PUT方法更新资源，使用 DELETE方法删除资源，以及使用 POST方法执行各种不安全和非幂等的操作。可以添加适当的 HTTP标头来描述请求和响应。
问题讨论
以下特性完全取决于保持请求和响应的可见性：
缓存
缓存响应内容，并在资源修改时使缓存自动失效。
乐观并发控制
检测并发写入，并在操作过期的表述时防止资源发生变更。
内容协商
在给定资源的多个可用表述中，选择合适的表述。
安全性和幂等性
确保客户端可以重复或重试特定的 HTTP请求。
当一个 Web服务无法保持可见性时，以上这些功能将无法正常工作。例如，当服务器对 HTTP的使用方式阻碍乐观并发时，您可能要被迫自己实现应用特定的并发控制机制。保持可见性让您可以使用现有的 HTTP 软件和基础设施来实现之前必须自己实现的功能。
HTTP通过以下途径来实现可见性：
● HTTP的交互是无状态的，任何HTTP中介都可以推断出给定请求和响应的意义，而无须关联过去或将来的请求和响应。
● HTTP使用一个统一接口，包括有 OPTIONS,GET,HEAD,POST,DELETE和 TRACE方法。接口中的每一个方法操作一个且仅有一个资源。每个方法的语法和含义不会因应用程序或资源的不同而发生改变。这就是为什么 HTTP以统一接口而闻名于世了。
● HTTP使用一种与 MIME类似的信封格式进行表述编码。这种格式明确区分标头和内容。标头是可见的，除了创建、处理消息的部分，软件的其他部分都可以不用关心消息的内容。
考虑一个更新资源的 HTTP请求：
❶ 请求行包含 HTTP方法、资源路径和 HTTP版本
❷ 请求的表述形式标头
❸ 请求的表述内容
❹ 响应状态行包含 HTTP版本、状态码和状态消息
❺ 响应的表述形式标头
❻ 响应的表述内容
这个例子的请求是一个 HTTP消息。消息的第一行描述了客户端所使用的协议和方法，接下来的两行是请求头。简单查看这三行信息，任何理解 HTTP的软件都可以明白请求的意图以及如何解析消息体。响应也是同样的，响应的第一行表示 HTTP版本、状态码和状态消息，接下来的两行告诉 HTTP软件如何解释消息。
对于 RESTful Web服务，您的主要目标必定是尽最大可能保持可见性。保持可见性非常简单，使用 HTTP方法时，其语义要与 HTTP所规定的语义保持一致，并添加适当的标头来描述请求和响应。
保持可见性的另一方面是使用适当的状态码和状态消息，以便代理、缓存和客户端可以决定请求的结果。状态码是一个整数，状态消息是文本。
正如我们将在1.2节讨论的内容一样，在某些情况下，您可能需要权衡其他特性，如网络效率、客户端的便利性以及分离关注点，为此放弃可见性。当您进行这种权衡时，应仔细分析对缓存、幂等性、安全性等特性的影响。1.2 何时需要权衡可见性
本节讨论了一些可能需要对可见性做出权衡的常见场合。
问题描述
您想知道有哪些常见场合可能需要让请求和响应降低对协议的可见性。
解决方案
当有多个共享数据的资源，或一个操作总是要修改多个资源时，请考虑降低可见性，以得到更好的信息抽象、更松散的耦合程度、更好的网络效率、更好的资源粒度，或者纯粹为了方便客户端使用。
问题讨论
可见性经常与其他架构要求相冲突，如抽象、松耦合、效率和信息粒度等。例如，考虑一个“人”资源与一个相关的“地址”资源，任何客户端都可以提交一个 GET请求得到这两个资源的表述，但为了方便客户端，服务器端可能会在“人”的资源表述中包含“地址”资源，就像下面这样：
让我们假设服务器允许客户端提交 PUT请求更新这些资源。当一个客户端修改了其中一个资源，相关资源的状态也会改变。然而，在 HTTP层面上，这些是相互独立的资源。只有服务器才知道它们是相互依赖的。数据的重叠是降低可见性的常见原因。
降低可见性的重要影响之一是缓存（详见第9章）。由于这些资源在 HTTP层面上是相互独立的，缓存将有两个“地址”的副本：一个独立的“地址”表述，以及作为“人”的一部分的表述，这样是很低效的。而且，在缓存中一个表述失效不会影响另一个表述，这样一来陈旧的表述就保留在缓存里了。在这个例子中，您可以包含一个指向地址的引用，以此避免包含详细地址，从而消除这些资源之间的重叠。可以使用链接（详见第5章）向其他资源提供引用。
尽管提供链接可以减少数据重叠，但这将迫使客户端发起更多的请求。
在这个例子中，可见性和客户端的易用性之间需要权衡，也许还包括网络效率。一个需要“人”资源的客户端可以通过单个请求得到“人”及“地址”的信息。
下面这些情况下，您可能需要为了其他好处放弃可见性：
方便客户端
为了方便客户端使用，服务器可能需要设计特定目标的粗粒度组件资源（例如，2.4节）。
抽象
为了抽象复杂的业务操作（包括事务），服务器可能需要使用控制器资源来改变其他资源（例如，2.6节）。这样的资源可以隐藏业务操作的实现细节。
网络效率
当客户端需要在短时间内连续执行几个操作时，可能需要将这些操作组合到一个批处理中，以降低网络延迟（例如，11.10节和11.13节）。
这些情况中，如果只关注可见性，您的 Web服务就不得不设计成以无重叠的独立资源形式来显示所有数据。按这种方式设计的 Web服务，可能导致资源粒度过细，客户端和服务器之间分离关注点不够，可详见2.6节中的例子。其他场合包括复制或合并资源、部分更新（详见第11章），可能也需要权衡可见性。假如在设计过程的早期即意识到其影响，为得到其他好处而降低可见性未必是坏事。1.3 如何维护应用程序状态
当您在阅读关于 REST 的文章时，经常得到这样的建议——在客户端保存应用程序状态。但什么是“应用程序状态”？应当如何在客户端保存这些状态？本节描述了保存应用程序状态的最佳实践。
问题描述
您想知道如何管理 RESTful Web服务的状态，这样就不需要依赖于服务器内存中的会话了。
解决方案
将应用程序状态编码到 URI里，并通过链接在表述中包含这些 URI（见第5章）。让客户端使用这些 URI与资源进行交互。如果状态过大，或出于安全或隐私考虑不能在网络中传输，则可以在持久化存储（如数据库或文件系统）中存储应用程序状态，并将其状态的引用编码在 URI中。
问题讨论
考虑一个简化的汽车保险应用，假定其中涉及两个步骤。第一步，客户端提交一个带有司机和车辆细节信息的请求，服务器返回一个一周内有效的报价。第二步，客户端提交购买保险的请求。在这个例子中，应用程序的状态就是报价。服务器需要知道从第一个步骤返回的报价，基于它才能给出第二个请求中的保单。应用程序状态是服务器需要在每个客户端的每个请求之间维护的状态。在客户端保持这个状态并不意味着要像 ASP.NET和 JavaServer Faces之类的Web框架所做的那样，把会话状态序列化到 URI或 HTML表单中。
由于 HTTP是无状态协议，每个请求与之前的请求都是独立的。然而，交互应用程序通常要求客户端执行时遵循特定顺序。这就要求服务器在协议之外暂时存储每个客户端在步骤序列里的当前位置。这里的诀窍是管理状态，这样就可以在可靠性、网络性能和可扩展性之间寻求平衡。
资源表述中的链接是保持应用程序状态的最好地方，如下所示：
❶ 一个包含应用程序状态的链接
在这个例子中，服务器把报价保存在数据存储里，并将主键编码在 URI中。当客户端使用该URI发起请求购买保险时，服务器可以通过这个主键恢复该应用程序状态。应当选择形如数据库或文件系统的持久化存储来保存应用程序状态。使用缓存或内存会话这样的非持久化存储会降低 Web服务的可靠性，例如在服务器重启时状态可能会丢失，非持久化存储解决方案也会降低服务器的可扩展性。
如果报价所需的数据量很小，服务器可以将状态编码在 URI中，正如稍后代码所展示的那样。当在数据库中保存应用程序状态时，使用数据库复制（replication）以便所有服务器实例都可以访问这些状态。如果应用程序状态不是永久的，可能需要在某些地方清理这些状态。
因为客户端需要在每个请求中发回以上这些数据，在链接中编码应用程序状态会降低网络性能。然而这样可以提高可扩展性，因为服务器不需要保存任何数据；也可以提高可靠性，因为服务器不需要使用复制。可以基于特定用例和状态数量，组合以上两种方式来管理应用程序状态，保持网络性能、可扩展性和可靠性之间的平衡。当在链接中保存应用程序状态时，一定要加入一些检查方式（如签名）来检测和防止伪造状态。详见12.5节的示例。1.4 如何在服务器端实现安全和幂等的方法
安全性和幂等性是服务器在实现某些方法时必须保证提供给客户端的。本节会讨论为什么安全性和幂等性如此重要，以及如何实现服务器端的安全性和幂等性。
问题描述
您想知道幂等性和安全性的具体含义，以及如何才能确保服务器提供的各种 HTTP方法实现了这两个特性。
解决方案
实现 GET,OPTIONS和 HEAD方法时，不要引起任何副作用。当客户端重新提交一个GET,HEAD,OPTIONS,PUT或 DELETE请求时，确保服务器提供同样的表述形式，并发情况除外（详第10章）。
问题讨论
安全性和幂等性是服务器要实现的 HTTP 方法特性，表1-1展示了哪个方法是安全的，哪个方法是幂等的。表1-1：HTTP方法的安全性与幂等性
实现安全方法
在 HTTP协议中，安全方法是不会引起副作用的。客户端在向安全方法发送请求时，无须担心会引起意料之外的副作用。为了提供这一保证，可以将安全方法实现为只读操作。
安全性并不意味着服务器每次都必须返回同一结果。它只是表明客户端可以发起请求，并知道它不会改变资源的状态。举例来说，以下两个请求都是安全的：
这个例子中，两次请求响应结果不同，可能是由其他客户端或后台操作引起的。
实现幂等方法
幂等性保证客户端重复发起某个请求的效果与一次请求的效果一致。幂等性大多与网络或软件故障息息相关。客户端可以重复这些要求并期望同样的结果。例如，考虑一个客户端更新产品价格的案例。
现在假设因为网络故障，客户端读不到响应。因为 HTTP 协议规定 PUT是幂等的，所以客户端可以重复提交请求：
要让这种方法正常运作，除 POST以外的所有方法都必须是幂等的。在编程语言的术语中，幂等方法类似于“setter”。举例来说，以下代码中的 setPrice 方法，调用多次和只调用一次产生的效果是一样的：
DELETE方法的幂等性
DELETE方法是幂等的。这意味着就算服务器在前一个请求中已经删除了资源，它也必须返回200（OK）响应码。但实际上，要把 DELETE实现为幂等操作，需要服务器追踪所有已经删除的资源。否则，它可能会返回一个404（Not Found）响应码。
就算服务器保留了所有已删除资源的记录，安全策略也可能要求服务器对所有已不存在的资源返回一个404（Not Found）响应码。1.5 如何在客户端处理安全和幂等方法
问题描述
您想了解如何实现幂等和（或）安全的 HTTP请求。
解决方案
把 GET,OPTIONS和 HEAD看做只读操作，需要时，可以随时发起这些请求。
在网络或软件出错时，重新提交 GET,PUT 和 DELETE 请求以做确认，提供If-Unmodified-Since和（或）If-Match条件头（详见第10章）。
不要重复提交 POST请求，除非客户端事先知道（例如，通过服务器的文档）服务器对任意特定资源的 POST操作的实现是幂等的。
问题讨论
安全方法
任何客户端都可以发起任意次数的 GET,OPTIONS和 HEAD请求。如果服务器的实现在处理这类请求时导致了意想不到的副作用，那可以直接认定服务器的 HTTP实现是错误的。
幂等方法
正如在1.4节所讨论的，幂等性保证了客户端可以在不能肯定服务器是否成功处理了请求时，重复发起这一请求。在 HTTP中，除了 POST以外的所有方法都是幂等的。在客户端实现上，当您在一个幂等方法上遇到软件或网络的错误时，可以实现一个重试请求的逻辑。下面是一段伪码片段：
在这个例子中，客户端实现了在网络出现故障时重复发起请求的逻辑，服务器端返回一个4xx或5xx错误的情况除外。客户端还要像往常那样继续处理 HTTP 层的错误（详见3.14节）。
因为 POST不是幂等的，上面的做法不能套用在 POST请求上，除非服务器明确声明可以这么做。10.8节描述了一种服务器为 POST请求提供幂等性的方法。1.6 何时使用GET方法
Web基础设施严重依赖于GET方法的幂等性和安全性。客户端期望能够重复发起GET请求，而不必担心造成副作用。缓存依赖于不需访问源服务器便能提供已缓存表述的能力。
问题描述
您想知道何时应该与何时不应该使用 GET请求，以及 GET请求使用不当的潜在后果。
解决方案
使用 GET方法进行安全与幂等的信息获取。
问题讨论
每个 HTTP方法都具有特定的语义。正如1.1节所讨论的，GET的目的是得到一个资源的表述，PUT用于建立或更新一个资源，DELETE用于删除一个资源，POST用于创建多个新资源或对资源进行多种其他变更。
在所有上述方法中，GET被滥用的情况最少，因为 GET既安全又幂等。不要把 GET方法用于不安全或非幂等操作。因为这样做可能会造成永久性的、意想不到的、不符合需要的资源改变。
大部分对 GET的滥用都是将它用在不安全操作上，以下是一些
试读结束[说明：试读内容隐藏了图片]