在不违反 REST 的情况下处理长查询 [英] Handling long queries without violating REST

问题描述

我们有一个 REST api，我们在坚持 REST 精神方面做得非常好.但是，我们有一个重要的消费者，他们正在请求一种方法来协调他们的数据存储.流程如下:

We have a REST api, and we've done a pretty good job at sticking to the spirit of REST. However, we have an important consumer, and they're requesting a way to reconcile their datastore. The flow works like this:

1. 消费者发出 GET 调用以检索在日期范围内创建的所有库存对象.假设这会返回 100 万个库存 VIN.
2. 消费者将负载与他们自己的数据存储区进行比较，发现他们缺少 5,000 个清单对象
3. 消费者想要使用 5,000 个 VIN ID 提出请求，并返回这 5,000 个对象.

问题在于，长查询字符串(vins 的 JSON 数组)与我们的服务器强加的查询字符串长度限制相撞.可能的想法 - 进行 5k 次单独调用(看起来很糟糕)，增加服务器上的查询字符串长度限制(不想这样做)，改用 POST(不是 RESTful?).

The problem is that the long query string (JSON array of vins) bumps into the query string length limits imposed by our server. Possbile ideas - make 5k separate calls (seems horrible), increase querystring length limit on server (would like not to do this), use POST instead (not RESTful?).

所以，我想知道 Roy Fielding 会做什么...

So, I'm wondering what Roy Fielding would do...

推荐答案

使用帖子而不创建资源对我来说似乎太脏了.最后，我们做到了在块"中请求的 ID 限制为 100 个.在实践中，这些请求很少会超过 100，因此利用 REST 原则来适应边缘情况似乎是一个坏主意.我确保在我们的 API 文档中明确定义了限制，完成并完成...

Using a post without creating a resource just seemed too dirty for me. In the end, we made it so that there was a limit of 100 ids requested in a "chunk". In practice, these requests will rarely be > 100, so hacking REST principles to accomodate an edge case seemed like a bad idea. I made sure the limitation was clearly defined in our API docs, done and done...

这篇关于在不违反 REST 的情况下处理长查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！