REST 的重点是资源以及客户端与服务器的解耦,但它不是简单的 CRUD 架构或协议。虽然 CRUD 和 REST 看起来非常相似,但通过 REST 原则管理资源通常也会有副作用 https://softwareengineering.stackexchange.com/questions/120716/difference-between-rest-and-crud。因此,将 REST 描述为简单的 CRUD 事物过于简单化了。
关于 REST 资源的批处理,底层协议(最常见的是 HTTP)确实定义了可以使用的功能。 HTTP 定义了一些可用于修改多个资源的操作。
POST
是该协议的万能瑞士军刀,可用于根据您的喜好管理资源。由于语义是由开发人员定义的,因此您可以使用它一次创建、更新或删除多个资源。
PUT
具有用请求的有效负载主体替换给定 URI 处可获取的资源状态的语义。如果您发送一个PUT
请求“列表”资源并且有效负载定义条目列表,您也可以实现批量操作。
POST 和 PUT 方法之间的根本区别是
通过所附表示的不同意图来突出显示。
POST 请求中的目标资源旨在处理
根据资源自身语义的封闭表示,
而 PUT 请求中的封闭表示定义为
替换目标资源的状态。
...
应用于目标资源的 PUT 请求可能会对
其他资源。例如,一篇文章可能有一个 URI
识别与以下版本不同的“当前版本”(资源)
标识每个特定版本的 URI(在某一时刻与当前版本共享相同状态的不同资源)
资源)。对“当前版本”URI 的成功 PUT 请求
因此,除了更改之外,还可能创建一个新版本资源
目标资源的状态,也可能导致链接
在相关资源之间添加。
(Source https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4)
PATCH
(RFC 5789 https://www.rfc-editor.org/rfc/rfc5789)尚未包含在 HTTP 协议中,尽管有很多框架支持。它主要用于一次更改多个资源或对资源执行部分更新,这PUT
如果更新的部分是其他资源的子资源,也可以实现;在这种情况下,它会对外部资源产生部分更新的影响。
重要的是要知道PATCH
请求包含服务器必须完成的将资源转换为其预期状态的必要步骤。因此,客户端必须获取当前状态并提前计算转换所需的必要步骤。关于这个主题的一篇内容非常丰富的博客文章是不要像白痴一样打补丁 http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/. Here JSON 补丁 http://jsonpatch.com/ (RFC https://www.rfc-editor.org/rfc/rfc6902) 是一种基于 JSON 的媒体类型,可以清晰地可视化 PATCH 概念。必须完全应用补丁请求(补丁请求中定义的每个操作)或根本不应用。因此,它需要事务范围的处理和回滚,以防任何操作失败。
有条件的请求,例如ETag
and IfModifiedSince
标头定义在RFC 7232 https://www.rfc-editor.org/rfc/rfc7232仅当请求应用于最新版本的资源时,才可以在 HTTP 请求中使用它来执行修改,因此与(分布式)数据库中的乐观锁定相关。
到目前为止,一切都很好。但是当我想删除1000条记录时该怎么办呢?
这取决于您将使用什么框架。如果支持的话PATCH
我明确投票支持PATCH
。如果没有,您使用起来可能会更安全POST
than PUT
作为非常严格的语义PUT
已经,因为语义由您明确定义。如果是批量删除,PUT
还可以通过将集合资源定位为空主体来使用,其结果是删除集合中的任何项目,从而清除整个集合。如果有些物品应该保留在收藏中,PATCH
or POST
可能更容易使用。