REST:通过一个请求更新多个资源-是标准的还是要避免的? [英] REST: Updating Multiple Resources With One Request - Is it standard or to be avoided?

问题描述

一个简单的REST API:

A simple REST API:

• GET:items/{id}-返回具有给定id的商品的说明
• 输入:items/{id}-更新或创建具有给定id的项目
• 删除:项目/{id}-删除具有给定ID的项目

现在有问题的API扩展名:

Now the API-extension in question:

• GET:items?filter-返回与过滤器匹配的所有项目ID
• PUT:项目-更新或创建一组由JSON有效负载描述的项目
• [[< Delete:items-删除由JSON有效负载描述的项目列表]]]<-不正确

• GET: items?filter - Returns all item ids matching the filter
• PUT: items - Updates or creates a set of items as described by the JSON payload
• [[DELETE: items - deletes a list of items described by JSON payload]] <- Not Correct

我现在对DELETE和PUT操作回收功能感兴趣，该功能可以通过PUT/DELETE项目/{id}轻松访问.

I am now being interested in the DELETE and PUT operation recycling functionality that can be easily accessed by PUT/DELETE items/{id}.

问题:提供这样的API是否常见?

Question: Is it common to provide an API like this?

另一种选择:在单连接多个请求时代，发出多个请求很便宜，并且由于更改成功或失败而可以更原子地工作，但是在NOSQL数据库时代，即使请求，列表中的更改也可能已经发生使用内部服务器或由于任何原因而进行的处理会死掉.

Alternative: In the age of Single Connection Multiple Requests issuing multiple requests is cheap and would work more atomic since a change either succeeds or fails but in the age of NOSQL database a change in the list might already have happend even if the request processing dies with internal server or whatever due to whatever reason.

[UPDATE]

考虑了白宫网络标准和

After considering White House Web Standards and Wikipedia: REST Examples the following Example API is now purposed:

一个简单的REST API:

A simple REST API:

• GET:items/{id}-返回具有给定id的商品的说明
• 输入:items/{id}-更新或创建具有给定id的项目
• 删除:项目/{id}-删除具有给定ID的项目

顶级资源API:

• GET:items?filter-返回与过滤器匹配的所有项目ID
• POST:项目-更新或创建JSON有效负载所描述的一组项目

不支持和禁止在/items上进行PUT和DELETE.

PUT and DELETE on /items is not supported and forbidden.

使用POST似乎可以解决问题，因为它是一种在封闭资源中创建新项目，而不是替换而追加的项目.

Using POST seems to do the trick as being the one to create new items in an enclosing resource while not replacing but appending.

HTTP语义POST 读取:

通过附加操作扩展数据库

Extending a database through an append operation

PUT方法将需要替换完整的集合以便返回由

Where the PUT methods would require to replace the complete collection in order to return an equivalent representation as quoted by HTTP Semantics PUT:

对给定表示形式的成功PUT建议，在同一目标资源上进行后续GET将导致在200(OK)响应中返回等效表示形式.

A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being returned in a 200 (OK) response.

[UPDATE2]

对于多个对象的更新方面似乎更一致的替代方法似乎是PATCH方法. 草案RFC 5789 中将PUT和PATCH的区别描述为:

An alternative that seems even more consistent for the update aspect of multiple objects seems to be the PATCH method. The difference between PUT and PATCH is described in the Draft RFC 5789 as being:

PUT和PATCH请求之间的差异反映在服务器处理封闭实体以修改由Request-URI标识的资源的方式中.在PUT请求中，封闭的实体被视为原始服务器上存储的资源的修改版本，并且客户端正在请求替换存储的版本.但是，对于PATCH，封闭的实体包含一组指令，这些指令描述了应如何修改当前驻留在源服务器上的资源以产生新版本. PATCH方法影响由Request-URI标识的资源，并且可能对其他资源也有副作用.即可以通过应用PATCH来创建新资源或修改现有资源.

The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.

因此，与POST相比，PATCH也可能是一个更好的主意，因为PATCH允许进行UPDATE，而POST仅允许附加意味着添加的内容，而无需进行修改.

So compared to POST, PATCH may be also a better idea since PATCH allows an UPDATE where as POST only allows appending something meaning adding without the chance of modification.

因此POST在这里似乎是错误的，我们需要将建议的API更改为:

So POST seems to be wrong here and we need to change our proposed API to:

一个简单的REST API:

A simple REST API:

• GET:items/{id}-返回具有给定id的商品的说明
• 输入:items/{id}-更新或创建具有给定id的项目
• 删除:项目/{id}-删除具有给定ID的项目

顶级资源API:

• GET:items?filter-返回与过滤器匹配的所有项目ID
• POST:项目-创建一个或多个项目，如JSON有效负载所述
• PATCH:项目-按照JSON有效负载的描述创建或更新一个或多个项目

推荐答案

您可以修补集合，例如

PATCH /items
[ { id: 1, name: 'foo' }, { id: 2, name: 'bar' } ]

从技术上讲，PATCH会在URL中标识记录(即PATCH /items/1而不是请求正文中的记录)，但这似乎是一个实用的解决方案.

Technically PATCH would identify the record in the URL (ie PATCH /items/1 and not in the request body, but this seems like a good pragmatic solution.

要支持在单个调用中进行删除，创建和更新，标准REST约定实际上并没有对此提供支持.一种可能性是特殊的批处理"服务，它使您可以将调用组合在一起:

To support deleting, creating, and updating in a single call, that's not really supported by standard REST conventions. One possibility is a special "batch" service that lets you assemble calls together:

POST /batch
[
  { method: 'POST', path: '/items', body: { title: 'foo' } },
  { method: 'DELETE', path: '/items/bar' }
]

为每个嵌入的请求返回带有状态代码的响应:

which returns a response with status codes for each embedded requests:

[ 200, 403 ]

并不是很标准，但是我已经做到了并且可以正常工作.

Not really standard, but I've done it and it works.

这篇关于REST:通过一个请求更新多个资源-是标准的还是要避免的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！