我们有一个REST API，我们在坚持REST精神方面做得非常好。但是，我们有一个重要的消费者，他们正在请求一种方法来协调他们的数据存储。流程如下：
问题是长查询字符串（vins的JSON数组）会碰到我们服务器强加的查询字符串长度限制。 Possbile想法 - 做5k单独调用（看起来很可怕），增加服务器上的查询字符串长度限制（不想这样做），改用POST（不是RESTful？）。
所以，我想知道罗伊菲尔丁会做什么......
答案 0 :(得分：3)
POST如何将带有ID列表的JSON文件提交给新资源，例如叫/inventory/difference？
如果计算时间过长，您可以使用202 Accepted回答并生成正在生成的资源的ID，然后在/inventory/difference/:id指回它。
答案 1 :(得分：2)
与moonwave99建议的有些相似，但你创建了一个名为“set”的资源。
您POST到/设置您希望在集合中的标识符列表。 POST的结果是指向指定特定集的资源的重定向URL。
所以：
POST /set
结果：
301 Moved Permanently
Location: /set/123
然后：
GET /set/123
返回集合中的项目列表。
集合与“获取差异”的用例正交，它们只是项目的汇编。
如果创建一个集需要很长时间，并且您认为该集本身是数据的快照，那么当用户尝试执行GET / set / 123时，只需回复202 Accepted，直到实际数据集已经完成。
然后您可以使用：
GET /set/123/identifiers
获取集合中实际标识符的集合，例如，如果您愿意。
您可以执行类似
的操作POST /setfromquery
并发送标准列表（名称如“John *”，city =“Los Angeles”等）。这并不需要它自己的特定资源，只需定义您的查询“语言”以包含ID的简单列表以及其他过滤条件。
设置操作（工会，差异等）。使用set资源可以完成许多强大的功能。
最后，当然，有一个很受欢迎的：
DELETE /set/123
答案 2 :(得分：1)
我认为任何人都不会因为GET不接受请求正文而使用POST来处理需要请求正文的请求。你只是务实。
我同意，提出5000个单独的请求或提高查询字符串限制是很难看的。 POST是前进的方向。
答案 3 :(得分：0)
使用帖子而不创建资源对我来说似乎太脏了。最后，我们制作了一个“大块”中要求的100个限制。实际上，这些请求很少是> 100，所以黑客入侵REST原则以容纳边缘案例似乎是一个坏主意。我确保在我们的API文档中明确定义了限制，完成并完成了......