我们有一个REST API，并且我们在坚持REST的精神做了很好的工作。 但是，我们有一个重要的消费者，他们正在请求的方式来调和自己的数据存储。 流程是这样的：
问题是，长查询字符串（VINS的JSON数组）撞到我们的服务器造成的查询字符串长度的限制。 Possbile想法 - 让5K单独调用（似乎可怕），加大对服务器的查询字符串长度的限制（想不要这样做），使用POST（不是REST风格？）。
所以，我想知道什么罗伊菲尔丁会怎么做？
怎么样一个POST提交与ID的列表中的JSON文件到一个新的资源，如所谓的/inventory/difference ？
如果计算去任何长，你可以接听202 Accepted和生成资源的id，然后在点回去吧/inventory/difference/:id 。
有点类似于moonwave99建议，而是创建一个名为资源的“设置”。
您张贴到/设置你想在一组标识符的列表。 自检的结果是一个URL重定向到资源名称的具体设置。
所以：
POST /set
结果：
301 Moved Permanently
Location: /set/123
然后：
GET /set/123
返回集合中的项目列表。
集是正交的“获取差异”的使用情况下，他们只是项目的汇编。
如果一组的创建需要很长的时间，你考虑集合本身是数据的快照，当用户尝试做了get / set / 123可以简单地接受了202回复直到实际数据集已完成。
然后，您可以使用：
GET /set/123/identifiers
要获得实际的标识符的集合中的集合，例如，如果你喜欢。
你可以这样做
POST /setfromquery
和发送的标准清单（名称，如“约翰*”，城市=“洛杉矶”等）。 这不真的需要它自己特定的资源，只是定义查询“语言”来既包括简单的ID列表以及其他可能的过滤标准。
Set操作（工会，差异等）。 强大的很多事情可以用一组资源来完成。
最后，当然，还有日益流行：
DELETE /set/123
我想没有人会指责你在身边工作取得不使用POST对于需要请求主体的请求，接受请求主体。 你只是务实。
我同意，让5000个个人请求或加大了查询字符串限制是丑陋的。 POST是前进的方向。
使用后无需创建资源似乎只是对我来说太肮脏。 最终，我们做到了，这样有一个“块”要求100个IDS的限制。 在实践中，这些要求很少会> 100，所以黑客REST原则，以适应边缘的情况下似乎是一个坏主意。 我确信限制在我们的API文档，做，做了明确的规定？
