在RESTful API中更新多个记录

我想知道在您不知道要更新的记录的ID的情况下，是否有RESTful方法来处理通过一个请求更新多个记录

例如：

您拥有资源

/jobs

。假设您能够按以下方式列出这些作业

GET/jobs？sort=priority&inprogress=false&limit=10

这将返回10个未按优先级顺序进行的作业的列表

现在假设您希望将这些作业的状态更改为inprogress=true。实现这一目标的宁静方式是什么？显然，您可以执行一个GET，然后分别更新其中的每一个，但是在执行GET和进行更新之间，您可能有另一个进程已经抓住了这些进程。然后你会得到一个失败的请求，因为这些请求已经被更新，这是我想要避免的主要事情

基于诸如GET请求之类的过滤执行更新是否是RESTful的

PATCH /jobs?sort=priority&inprogress=false&limit=10

{[op:"replace", path:"/inprogress", value:true]}

因此，这将按优先级顺序更新前10个未进行的作业，将它们更改为正在进行并返回

---

这是安静的吗？还是有更好的方法以RESTful方式实现这一点？

更新：

在阅读了评论之后，我意识到更新资源的命令实际上是补丁，所以这个答案不适用。很抱歉给你带来了困惑

---

在Rest定义中，GET（以及PUT）操作必须是幂等的：这意味着（请参阅）

“N>0个相同请求的副作用与单个请求相同：

（所以，当使用幂等运算时，您的客户端应用程序可以放心地重复任何调用，而不会产生意外的结果）

您假装使用GET的方式显然不符合此限制，您必须使用POST来“停止”此进程

此外，我还将使用一些不同的资源来明确区分此操作：例如

POST /activate-jobs?sort=priority&limit=10

---

实际上，这与REST无关。REST支持使用标准（统一接口/自描述性消息），并且是一个标准…您不必使用不同的URL，也可以使用相同的URL。@inf3rno如果您不指定其他内容，并且使用常见的HTTP方法，则可以理解为您指的是HTTP Rest实现。在该实现中，GET、HEAD、PUT和DELETE方法必须是幂等的，因此他打算使用GET does没有遵循那个规范。关于URI：我并不是说他必须使用另一个URI，这只是一个建议。我相信你会同意，在描述动作的动作中使用名称是一个很好的做法。我同意，但客户端不应该知道URL的结构，例如，你必须添加一些元数据充足的IANA链接关系到链接，并检查这些链接以决定遵循哪个。我猜Chris甚至不使用链接（HATEOAS），所以这甚至不是一个REST服务，只是一些使用HTTP标准的RPC…PATCH不是一个幂等方法，所以它可以用于他想要的。你是对的：要验证接口是否遵循HATEOAS原则，需要涉及的事情很多。但你只能假设他不使用链接关系，因为他没有显示接口的“rest”…我只是指出了它没有遵循HTTP rest原则的第一个地方（撇开GET和PATCH之间的分歧…）我不确定我的GET请求如何不是幂等的？它不会以任何方式影响数据的状态。修补程序请求是更新数据的内容。修补程序也会返回更新的数据。此接口当前不存在，我目前处于设计阶段