RESTful API 和批量操作

Question

我有一个在共享数据库上执行 CRUD 操作的中间层。当我将产品转换为 .NET Core 时，我想我也会考虑将 REST 用于 API，因为 CRUD 应该是它擅长的地方。看起来 REST 是一个很好的单记录操作解决方案，但是当我想删除，比如说，1000 条记录时会发生什么？

每个专业的多用户应用程序都会有一些乐观并发检查的概念:你不能让一个用户在没有反馈的情况下抹杀另一个用户的工作。据我了解，REST 使用 HTTP ETag header 记录处理此问题。如果客户端发送的 ETag 与服务器的标签不匹配，那么您将发出 412 Precondition Failed。到目前为止，一切都很好。但是我要删除1000条记录怎么办呢？ 1,000 次单独调用的来回时间相当可观，那么 REST 如何处理涉及乐观并发的批处理操作？

Answer 1

REST 的重点是资源和客户端与服务器的解耦，尽管它不是简单的 CRUD 架构或协议(protocol)。虽然 CRUD 和 REST 看起来非常相似，但通过 REST 原则管理资源 can often also have sideeffects .因此，将 REST 描述为简单的 CRUD 是过于简单化了。

关于 REST 资源的批处理，底层协议(protocol)(通常是 HTTP)确实定义了可以使用的功能。 HTTP 定义了几个可用于修改多个资源的操作。

POST 是协议(protocol)的万能瑞士军刀，可用于按您的喜好从字面上管理资源。由于语义由开发人员定义，您可以使用它一次创建、更新或删除多个资源。

PUT 具有将在给定 URI 处可获得的资源状态替换为请求的有效负载主体的语义。如果您向“列表”资源发送一个 PUT 请求并且负载定义了一个条目列表，您也可以实现批处理操作。

The fundamental difference between the POST and PUT methods ishighlighted by the different intent for the enclosed representation.The target resource in a POST request is intended to handle theenclosed representation according to the resource's own semantics,whereas the enclosed representation in a PUT request is defined asreplacing the state of the target resource.

...

A PUT request applied to the target resource can have side effects onother resources. For example, an article might have a URI foridentifying "the current version" (a resource) that is separate fromthe URIs identifying each particular version (different resources that at one point shared the same state as the current versionresource). A successful PUT request on "the current version" URImight therefore create a new version resource in addition to changingthe state of the target resource, and might also cause links to beadded between the related resources.(Source)

PATCH ( RFC 5789 ) 尚未包含在 HTTP 协议(protocol)中，尽管有很多框架支持。它主要用于一次更改多个资源或对资源执行部分更新，如果更新的部分是其他资源的子资源，PUT 也可以实现；在这种情况下，它具有对外部资源进行部分更新的效果。

重要的是要知道 PATCH 请求包含服务器必须完成的将资源转换为预期状态的必要步骤。因此，客户端必须获取当前状态并预先计算转换所需的必要步骤。关于此主题的一篇内容丰富的博客文章是 Don't patch like an idiot .这里JSON Patch ( RFC ) 是一种基于 JSON 的媒体类型，可以清楚地可视化 PATCH 概念。必须完全应用补丁请求(补丁请求中定义的每个操作)或根本不应用。因此，它需要事务范围内的处理和回滚，以防任何操作失败。

ETag 和 IfModifiedSince header 等条件请求在 RFC 7232 中定义并且仅当请求应用于最新版本的资源时才可用于 HTTP 请求以执行修改，因此与(分布式)数据库中的乐观锁定相关。

So far, so good. But what do I use when I want to delete 1,000 records?

这取决于您将使用的框架。如果它支持PATCH，我显然会投票支持PATCH。如果不是，使用 POST 可能比使用 PUT 更安全，因为 PUT 具有非常严格的语义，因为语义很清楚由你定义。在批量删除的情况下，PUT 也可以通过将集合资源定位为空主体来使用，其结果是删除集合中的任何项目，从而清除整个集合。如果某些项目应该保留在集合中，PATCH 或 POST 可能更易于使用。