创建RESTful复杂查询的最佳方法是什么？

What's the best way retrieve complex queries from a REST service?

从REST服务检索复杂查询的最佳方法是什么?

Suppose I want to get X collections, apply filters and equations to each one, combine the collections using some other operation and return one result, everything in one request.

假设我想获得X集合,为每个集合应用过滤器和方程式,使用其他操作组合集合并返回一个结果,一个请求中的所有内容。

It is just too complex (and big) to put everything in the querystring since I could combine more than 300 collections (plus the operators and filters to each one).

由于我可以组合300多个集合(以及每个集合的运算符和过滤器),因此将所有内容放在查询字符串中太复杂(而且很大)。

I thought about using POST to send a XML object describing the query to something like:

我想过使用POST将描述查询的XML对象发送到:

http://mydomain/collections/complexQuery

It would return an unique ID and then I could use GET to retrieve the complexQuery result:

它将返回一个唯一的ID,然后我可以使用GET来检索complexQuery结果:

http://mydomain/collections/complexQuery/{queryId}

Jason S:

That's the idea. The POST will take an XML representation of the query, with the "where" parameters already (they can be too many). The query will be executed only when the GET arrives. I could let the query object available just for some time and delete it later.

这就是主意。 POST将采用查询的XML表示形式,其中“where”参数已经存在(它们可能太多)。只有在GET到达时才会执行查询。我可以让查询对象可用一段时间并稍后删除它。

Is this a good solution? Am I still RESTful doing this?

这是一个好的解决方案吗?我还在RESTful吗?

4 个解决方案

#1

Sounds RESTful to me if you're using a unique ID. If the query result set is large you might want to include a way of asking for result set rows M - N where M,N are parameters.

如果你使用的是唯一的ID,那对我来说听起来很RESTful。如果查询结果集很大,您可能希望包括一种询问结果集行M-N的方法,其中M,N是参数。

I guess an advantage of your unique ID approach (w/ query definition state stored on the server) is you could use the result of the query as a parameter of another query. Maybe even separate out POSTING the definition of a query from the execution of the query.

我猜你的唯一ID方法的优势(w /查询定义状态存储在服务器上)是你可以使用查询的结果作为另一个查询的参数。甚至可能将查询的定义与执行查询分开。

#2

This is the standard RESTful approach. POST to the resource and expect a 201 Created (no entity body) with the URI to the created results in the Location header. You can also return the results with a 200 OK response, and optionally a URI pointing to the results for future (de)reference in the response along with a copy of the results.

这是标准的RESTful方法。 POST到资源并期望201 Created(没有实体主体)具有创建的URI的结果在Location头中。您还可以使用200 OK响应返回结果,也可以选择一个URI指向响应中未来(de)引用的结果以及结果副本。

#3

It is OK. But it introduces a few problems:

没关系。但它引入了一些问题:

You have to persist the query data on the server, when do you clean old queries?

您必须在服务器上保留查询数据,何时清理旧查询?

If you clean old queries, it means you can't provide links to saved queries because they might have been already cleaned.

如果清理旧查询,则表示您无法提供已保存查询的链接,因为它们可能已被清除。
Even simple query requires two round-trips (POST & then GET)

即使是简单的查询也需要两次往返(POST然后GET)
Your client needs to be familiar with the XML schema you expect, instead of the well known: param1=val1&param2=val2

您的客户端需要熟悉您期望的XML模式,而不是众所周知的:param1 = val1&param2 = val2

#4

sorry, my ignorance...

对不起,我的无知......

but why not just returning the data with the post???

但为什么不直接用帖子返回数据???

I can understand why it's wrong to update data with a get, but I don't see why it should be mandatory to update data with every post?

我能理解为什么用get来更新数据是错误的,但是我不明白为什么每个帖子都要强制更新数据?

I also understand that the idea is that every get method could be potentially cached (because they don't modify data), but in this case they could only be cached if the temporarily saved query is still active... which adds another layer of complexity...

我也理解这个想法是每个get方法都可能被缓存(因为它们不会修改数据),但在这种情况下,如果临时保存的查询仍处于活动状态,它们只能被缓存...这会添加另一层复杂...

I also thought that one of the principles of rest is to define stateless (like the http protocol) interfaces, and in this case the server is maintaining a state to solve the query...

我还认为休息的原则之一是定义无状态(如http协议)接口,在这种情况下服务器维护一个状态来解决查询...

I've just started reading about rest and there area several things that I just don't yet understand...

我刚刚开始阅读有关休息的内容,还有几个我还不了解的事情......

#1