问处理长查询而不违反REST

EN

在没有创建资源的情况下使用帖子对我来说太脏了。最后，我们实现了这样一个限制，即在一个“块”中请求100个ids。在实践中，这些请求很少会超过100，因此，利用REST原则来容纳边缘情况似乎是个坏主意。我确保在API文档中清楚地定义了限制，完成和完成了.

如果一个POST将带有id列表的JSON文件提交到一个新的资源，例如，名为/inventory/difference

如果计算时间太长，您可以使用202 Accepted和正在生成的资源id来回答，然后将其指向/inventory/difference/:id。

这与moonwave99的建议有些相似，但是您创建了一个名为"set“的资源。

您向/set发布希望在集合中的标识符列表。POST的结果是将URL重定向到指定特定集合的资源。

所以：

POST /set

结果：

301 Moved Permanently
Location: /set/123

然后：

GET /set/123

返回集合中的项列表。

集合与“获取差异”的用例正交，它们只是项的汇编。

如果创建集合需要很长时间，并且您认为集合本身是数据的快照，则当用户尝试执行GET / set /123时，可以简单地使用202接受的答复，直到实际数据集完成为止。

然后，您可以使用：

GET /set/123/identifiers

要获取集合中的实际标识符，例如，如果您愿意的话。

你可以做这样的事

POST /setfromquery

并发送一份标准列表(如"John*“、city =”洛杉矶“等)。这实际上并不需要它自己的特定资源，只需定义您的查询“语言”，就可以包含简单的ID列表以及其他筛选条件。

设置操作(工会、差异等)。许多强大的事情可以用一个集合的资源来完成。

最后，当然，有一个永远流行的：

DELETE /set/123