在 REST Web 服务中处理批处理操作的模式? [英] Patterns for handling batch operations in REST web services?

问题描述

在 REST 风格的 Web 服务中，对于资源的批处理操作有哪些经过验证的设计模式?

What proven design patterns exist for batch operations on resources within a REST style web service?

我试图在性能和稳定性方面在理想和现实之间取得平衡.我们现在有一个 API，其中所有操作都可以从列表资源(即:GET/user)或单个实例(PUT/user/1、DELETE/user/22 等)中检索.

I'm trying to be strike a balance between ideals and reality in terms of performance and stability. We've got an API right now where all operations either retrieve from a list resource (ie: GET /user) or on a single instance (PUT /user/1, DELETE /user/22, etc).

在某些情况下，您希望更新一整套对象的单个字段.来回发送每个对象的整个表示来更新一个字段似乎非常浪费.

There are some cases where you want to update a single field of a whole set of objects. It seems very wasteful to send the entire representation for each object back and forth to update the one field.

在 RPC 风格的 API 中，你可以有一个方法:

In an RPC style API, you could have a method:

/mail.do?method=markAsRead&messageIds=1,2,3,4... etc. 

这里的 REST 等价物是什么?或者时不时地妥协一下是否可以.添加一些可以真正提高性能等的特定操作是否会破坏设计?现在所有情况下的客户端都是一个 Web 浏览器(客户端的 javascript 应用程序).

What's the REST equivalent here? Or is it ok to compromise now and then. Does it ruin the design to add in a few specific operations where it really improves the performance, etc? The client in all cases right now is a Web Browser (javascript application on the client side).

推荐答案

批处理的一个简单 RESTful 模式是利用集合资源.例如，一次删除多条消息.

A simple RESTful pattern for batches is to make use of a collection resource. For example, to delete several messages at once.

DELETE /mail?&id=0&id=1&id=2

批量更新部分资源或资源属性稍微复杂一些.也就是说，更新每个标记为读取的属性.基本上，不是将属性视为每个资源的一部分，而是将其视为放置资源的桶.已经发布了一个示例.我稍微调整了一下.

It's a little more complicated to batch update partial resources, or resource attributes. That is, update each markedAsRead attribute. Basically, instead of treating the attribute as part of each resource, you treat it as a bucket into which to put resources. One example was already posted. I adjusted it a little.

POST /mail?markAsRead=true
POSTDATA: ids=[0,1,2]

基本上，您正在更新标记为已读的邮件列表.

Basically, you are updating the list of mail marked as read.

您也可以使用它来将多个项目分配给同一类别.

You can also use this for assigning several items to the same category.

POST /mail?category=junk
POSTDATA: ids=[0,1,2]

进行 iTunes 风格的批量部分更新显然要复杂得多(例如，artist+albumTitle 但不是 trackTitle).水桶比喻开始失效.

It's obviously much more complicated to do iTunes-style batch partial updates (e.g., artist+albumTitle but not trackTitle). The bucket analogy starts to break down.

POST /mail?markAsRead=true&category=junk
POSTDATA: ids=[0,1,2]

从长远来看，更新单个部分资源或资源属性要容易得多.只需使用子资源即可.

In the long run, it's much easier to update a single partial resource, or resource attributes. Just make use of a subresource.

POST /mail/0/markAsRead
POSTDATA: true

或者，您可以使用参数化资源.这在 REST 模式中不太常见，但在 URI 和 HTTP 规范中是允许的.分号用于分隔资源中水平相关的参数.

Alternatively, you could use parameterized resources. This is less common in REST patterns, but is allowed in the URI and HTTP specs. A semicolon divides horizontally related parameters within a resource.

更新几个属性，几个资源:

Update several attributes, several resources:

POST /mail/0;1;2/markAsRead;category
POSTDATA: markAsRead=true,category=junk

更新多个资源，只有一个属性:

Update several resources, just one attribute:

POST /mail/0;1;2/markAsRead
POSTDATA: true

更新多个属性，只更新一个资源:

Update several attributes, just one resource:

POST /mail/0/markAsRead;category
POSTDATA: markAsRead=true,category=junk

RESTful 的创造力比比皆是.

The RESTful creativity abounds.

这篇关于在 REST Web 服务中处理批处理操作的模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！