问题描述
我有一个中间层，可以在共享数据库上执行CRUD操作.当我将产品转换为.NET Core时，我想我也会考虑将REST用于API，因为CRUD应该可以很好地发挥作用. REST似乎是单记录操作的绝佳解决方案，但是当我想删除1000条记录时会发生什么?
I have a middle tier which performs CRUD operations on a shared database. When I converted the product to .NET Core I thought I'd also look at using REST for the API as CRUD is supposed to be what it does well. It seems like REST is a great solution for single record operations, but what happens when I want to delete, say, 1,000 records?
每个专业的多用户应用程序都将具有一些乐观并发检查的概念:您不能让一个用户在没有任何反馈的情况下消灭另一位用户的工作.据我了解，REST使用HTTP ETag标头记录处理此问题.如果客户端发送的ETag与服务器的标签不匹配，则您发出 412先决条件失败.到目前为止，一切都很好.但是，当我要删除1,000条记录时该怎么用?来回进行1,000次单独调用的时间相当可观，那么REST如何处理涉及 Optimistic Concurrency (优化并发)的批处理操作?
Every professional multi-user application is going to have some concept of Optimistic Concurrency checking: you can't have one user wipe out the work of another user without some feedback. As I understand it, REST handles this with the HTTP ETag header record. If the ETag send by the client doesn't match the server's tag, then you issue a 412 Precondition Failed. So far, so good. But what do I use when I want to delete 1,000 records? The back-and-forth time for 1,000 individual calls is considerable, so how would REST handle a batch operation that involved Optimistic Concurrency?
推荐答案
REST的重点是资源和客户端与服务器的分离，尽管它不是简单的CRUD体系结构或协议.尽管CRUD和REST看起来非常相似，但通过REST原理管理资源通常也会产生副作用.因此，将REST描述为简单的CRUD实在是太简单了.
RESTs focus is on resources and the decoupling of clients from servers, it is though not a simple CRUD architecture or protocol. While CRUD and REST seem to be very similar, managing resources through REST principles can often also have sideeffects. Therefore, describing REST as simple CRUD thing is an oversimplification.
关于REST资源的批处理，基础协议(通常是HTTP)确实定义了可以使用的功能. HTTP定义了几个可用于修改多个资源的操作.
In regards to batch-processing of REST resources, the underlying protocol (most often HTTP) does define the capabilities that can be used. HTTP defines a couple of operations that can be used to modify multiple resources.
POST是该协议的万能瑞士军刀，可用于按您的喜好从字面上管理资源.由于语义是开发人员定义的，因此您可以使用它一次创建，更新或删除多个资源.
POST is the all-purpose, swiss-army knife of the protocol and can be used to literally manage resources to your likings. As the semantics are defined by the developer you can use it to create, update or delete multiple resources at once.
PUT具有用请求的有效内容主体替换在给定URI处可获得的资源状态的语义.如果将"PUT"请求发送到列表"资源，并且有效负载定义了条目列表，则也可以实现批处理操作.
PUT has the semantics of replacing the state of a resource obtainable at a given URI with the payload body of the request. If you send a PUT request to a "list"-resource and the payload defines a list of entries, you can achieve a batch operation as well.
...
尽管
PATCH( RFC 5789 )尚未包含在HTTP协议中由大量框架支持.它主要用于立即更改多个资源或对资源执行部分更新，如果更新的部分是某些其他资源的子资源，则PUT也可以实现.在这种情况下，它会对外部资源进行部分更新.
PATCH (RFC 5789) is not yet included in the HTTP protocol, though supported by plenty frameworks. It is primarily used to alter multiple resources at once or to perform partial updates on resources, which PUT is also able to achieve if the updated part is a sub-resource of some other resource; in that case it has the effect of a partial update on the outer resource.
重要的是要知道PATCH请求包含服务器必须完成的必要步骤，以将资源转换为预期状态.因此，客户必须获取当前状态并预先计算转换所需的必要步骤.关于此主题的非常有用的博客文章是不要像白痴一样打补丁.此处 JSON补丁( RFC )是一种基于JSON的媒体类型，可以清晰地形象化PATCH概念.必须完全应用补丁请求(补丁请求中定义的每个操作)，或者根本不应用补丁请求.因此，在任何操作失败的情况下，都需要进行事务范围的处理和回滚.
It is important to know that a PATCH request contains the necessary steps a server has to fulfill to transform a resource to its intended state. A client therefore has to grab the current state and calculate the necessary steps needed for the transformation beforehand. A very informative blog post on this topic is Don't patch like an idiot. Here JSON Patch (RFC) is a JSON based media type that visualizes the PATCH concept clearly. A patch request has to be applied either fully (each operation defined in the patch request) or applied not at all. It therefore requires a transaction scoped handling and a roll back in case any of the operations failed.
ETag和IfModifiedSince标头之类的条件请求在 RFC 7232 中定义仅当请求应用于最新版本的资源并因此与乐观地锁定(分布式)数据库相关联时，才可以在HTTP请求中使用该请求来执行修改.
Conditional requests like ETag and IfModifiedSince headers are defined in RFC 7232 and can be used in HTTP requests to perform the modifications only if the request is applied on the most recent version of resource and therefore correlates to an optimistic locking in (distributed) databases.
这取决于您将使用的框架.如果它支持PATCH，我显然会投票支持PATCH.如果不是这样，由于PUT的限制性非常严格，因此使用POST可能比PUT更安全，因为这样您就可以清楚地定义这些语义.在批量删除的情况下，也可以使用PUT，方法是将集合资源定位为空主体，从而删除集合中的所有项目，从而清除整个集合.但是，如果某些项目应保留在集合中，则PATCH或POST可能更易于使用.
This depends on what framework you'll use. If it supports PATCH I clearly vote for PATCH. In case it does not, you are probably safer to use POST than PUT as of the very restrictive semantics PUT has, as the semantics are clearly defined by you then. In case of a batch-delete, PUT can also be used by targeting the collection resource with an empty body which has the result of removing any items in the collection and therefore clearing the whole collection. If some of the items should remain in the collection though, PATCH or POST are probably more easy to use.
这篇关于RESTful API和批量操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！