文章目录
  1. 1. 如何复制资源
  2. 2. 如何合并资源
  3. 3. 如何移动资源
  4. 4. 何时使用WebDAV
  5. 5. 如何支持跨域服务器的操作
  6. 6. 如何获取资源的快照
  7. 7. 如何撤销资源更新
  8. 8. 如何为部分更新提炼资源
  9. 9. 如何使用PATCH方法
  10. 10. 如何批量处理相似的资源
  11. 11. 如何触发批量操作
  12. 12. 何时使用POST来合并多个请求
  13. 13. 如何支持批量请求
  14. 14. 如何支持事务

本章我们继续介绍一些更具挑战性的问题,或许也已经超出了REST统一接口约束的领域。本章的内容主要涉及创建副本,创建快照,移动和合并,批量处理请求以及对事务的支持。

如何复制资源

为了复制资源而不泄漏服务器实现细节,可以设计一个用于复制的控制器资源。客户端向控制器发送POST请求复制资源。为了实现条件POST,可以提供一次性URI。控制器创建副本后,返回状态码201 (Created)及Location头带有副本URI。

如何合并资源

为了合并两个或多个资源,可以设计一个用于合并的应用程序特定控制器资源。客户端想控制器发送GET请求,其查询参数包含待合并资源的URI或标识符。服务器返回Last-Modified、ETag头和包含待合并资源摘要的表述体。ETag由时戳和随机数连接串构成。为了验证摘要,客户端向同一地址发送带有If-Unmodified-Since和If-Match头的POST请求发起合并。服务器合并后在事务日志中保留If-Match头的值并返回状态码201 (Created)及含有合并后资源URI的Location头。如果客户端再发送相同If-Match头的POST请求,服务器返回状态码412 (Preconditon Failed)。

如何移动资源

为了移动资源,服务器会提供负责移动资源控制器的链接或链接模板以使客户端可以发送POST请求,并在完成请求后根据输出返回状态码201 (Created)或303 (See Other)。

何时使用WebDAV

WebDAV (RFC 4918)是用于资源分布式创作和版本管理的HTTP扩展,它扩展了一些HTTP方法和头用于管理文件和文档。当Web服务是内容创作应用且服务器支持WebDAV时使用WebDAV特定方法,避免对其他类型应用使用WebDAV。

方法                介绍
PROPFIND        WebDAV中的文档具有属性,客户端可用此方法获得属性
PROPPATCH        客户端用此方法设置、添加或修改资源属性
MKCOL        WebDAV可以将文档放入集合(文件夹),客户端可用此方法创建集合
COPY        客户端可用此方法复制资源
MOVE        客户端可用此方法移动资源
LOCK        客户端可用此方法对给定文档加锁,以支持悲观并发控制
UNLOCK        客户端可用此方法对给定文档去锁

如何支持跨域服务器的操作

为了支持跨服务器边界的操作(例如,将用户配置从一个应用移植到另一个应用,将文档从草稿服务器发布到生产服务器),需要服务器之间彼此就数据格式、后台接口、并发控制、数据加载、范式化和存储等方面协作、设计和实现设计跨服务器操作。

如何获取资源的快照

wiki的网页都会维护当前和过去的修订历史,以便客户可以获取、比较和评估页面改变。为了支持资源以往历史快照,服务器在收到客户端PUT请求更新资源时,在更新资源之前会默认创建快照(资源副本),并在更新后的资源表述中包含快照链接,快照表述中包含更新后资源链接。当用户发送DELETE请求,删除资源及所有快照。

如何撤销资源更新

提供用于撤销操作的控制器资源。当客户端发送POST请求进行撤销操作,在事务日志中记录资源当前状态以用于审计。服务器将资源状态恢复到上一快照并将客户端重定向到资源URI。

如何为部分更新提炼资源

当资源很大而改动很小时,发送GET请求获取整个表述、进行小的修改、发送PUT请求将整个表述传回服务器进行更新很费时费带宽。为了支持对资源进行部分更新,可以将可修改的资源部分封装为一个新资源。客户端通过PUT请求更新该新资源,等效于部分更新原来的资源。

如何使用PATCH方法

HTTP PUT方法用于对资源的整个更新或替换,PATCH方法(RFC 5789)用于支持部分更新。PATCH方法不是安全和幂等的,请求体是一系列对资源进行改变的表述。当收到请求,服务器将整个补丁原子性地施加于资源,并返回响应码 200 (OK)或204 (No Content)。如果服务器无法将整体补丁施加于资源,就不会做任何局部修改。可以通过请求中包含If-Unmodified-Since和/或If-Match头支持条件PATCH请求,如果不匹配则返回状态码412 (Precondition Failed)。建议在OPTIONS响应的Allow头支持PATCH,并在PTACH方法包含Accept-Patch头,其值为支持的媒体类型。

如何批量处理相似的资源

当客户端需要为不同资源提交若干类似请求时,只要对每个资源的操作是相同的且资源是类似的,可以将这些操作组合成一个针对集合资源的单个操作。使用POST请求和集合资源一次性批量创建若干资源。服务器为集合资源分配一个URI,并使用状态码303 (See Other)重定向到该集合资源,集合资源表述包含所有新创建资源的链接。使用PUT请求更新或DELETE请求删除若干资源与创建过程类似,以上操作必须是原子化的。

如何触发批量操作

服务器需要设计一个控制器资源用于执行批量操作。如果客户端需要跟踪操作或客户端需要提交大量用于操作的数据,返回状态码202 (Accepted)以进行异步操作,否则返回200 (OK)或204 (No Content)。

何时使用POST来合并多个请求

将几个HTTP组合成一个HTTP请求以支持批量处理的用例不是少数。下面列举了一些通常使用的技术实现:

  1. 客户端将几个HTTP请求序列化到一个JSON对象、或一个XML文档、或multipart/mixed消息的一部分。
  2. 客户端创建一个信封跟是将多个请求组合进入一个消息。
  3. 客户端向服务器的分批终点(batch end point)资源发送POST请求。
  4. 服务器接收到消息,打开信封,重构多个HTTP请求并分发到服务器的相关URI。或者服务器绕过HTTP将请求直接派发到能处理这种请求的代码。
  5. 服务器收集每个请求的响应并序列化为一个消息返回到客户端。
  6. 客户端打开信封并处理每个响应消息

避免这种将多个HTTP请求封装入一个POST请求隧道的做法。因为通常隧道方案有以下不利之处:

  1. 并发: HTTP通过Last-Modified和ETag头来实现乐观并发检查。将多个HTTP请求封装进一个HTTP请求隧道的批量操作使并发检查变得困难,因为服务器需要为批量操作中每一个任务进行并发检查。
  2. 原子性: HTTP请求是原子性的。每个请求执行单个任务,服务器在错误发生时确保数据的原子性和一致性。将多个任务混入一个请求、尤其是某些操作依赖于同一请求的前一操作是否成功的批量操作使Web服务很难确保原子性和进行错误恢复。
  3. 可见性: 将多个操作封装到一个HTTP请求隧道使中间节点无法对批量处理内的操作响应可见。此外检测请求防止拒绝攻击的典型安全方法几乎不可能捕捉到批量操作中的可疑请求,因此可能导致拒绝服务攻击。
  4. 错误处理: 用于批量操作的错误处理和报告更为复杂。单个批量请求的结构可能混杂成功和失败响应。
  5. 可扩展性: 一般用于批量操作的理由依赖批量处理比执行每个单个请求更可扩展这样的假设。当单个服务器收到非常多的批量处理,请求会降低服务器的响应能力。发送很多批量客户端处理到单个服务器的应用比不支持批量处理的相同应用性能可能更低。

如何支持批量请求

分析导致促成使用隧道技术的用例,设计应用特有的控制器资源支持相同需求。由于请求使用的是处理请求资源的单个URI,所以请求可见。由于仅返回一个状态码,所以响应可见。

如何支持事务

RESTful web服务在下列场景可能会需要处理事务:

  1. 客户端执行操作流的一些列步骤。客户端在取消操作流时要撤销所有已完成的数据变动。
  2. 客户端同若干服务器顺序交互以实现应用操作流,客户端可能希望恢复任何状态改变或持久化存储状态。

可以提供对数据进行原子化操作的资源。将未提交状态视为应用状态(并将其加入URI中)。如果服务器需要允许客户端撤销操作,使用适当的PUT、DELETE或POST抵消已有的改变。

文章目录
  1. 1. 如何复制资源
  2. 2. 如何合并资源
  3. 3. 如何移动资源
  4. 4. 何时使用WebDAV
  5. 5. 如何支持跨域服务器的操作
  6. 6. 如何获取资源的快照
  7. 7. 如何撤销资源更新
  8. 8. 如何为部分更新提炼资源
  9. 9. 如何使用PATCH方法
  10. 10. 如何批量处理相似的资源
  11. 11. 如何触发批量操作
  12. 12. 何时使用POST来合并多个请求
  13. 13. 如何支持批量请求
  14. 14. 如何支持事务