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 is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource.

...

A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added 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 可能更易于使用。