Re: NEW PREFERENCE - return=query-result

Matt,
    Thanks for the comments.

    The proposed "transient" preference is a preference in the sense that the server still can ignore it. In that case, the server would just create the query definition. The client side will do the following:
    1. POST /searches (with body=query definition)
        Server returns something like:
        201 CREATED
        Location: /searches/foobar
    2. GET /searches/foobar/result
        to get the query executed and return the query result
    3. DELETE /searches/foobar
        A responsible client needs to delete the resource since it won't be used any more.

    I agree that the "transient" preference alters the server behavior. I think any preference header alters the server behavior in some way but I think your concern is that this alters the most basic behavior of the server (the basic part is creating the resource). 

    We have been exploring different options of supporting the adhoc query in a "standard" way. We could do the 3 steps way, but it is a lot of overhead. 
    We could enhance out specific media type and include "transient" information inside the query definition itself in the payload. It works only for our query definitions and won't work for other media types.
    (If we had SEARCH verb, it would solve our problem, but it has not been approved yet.)

    I have been thinking whether this can be make more generic and applied to broader scope instead of this narrow use case. Yes it is kind of related to caching. Following that line of thought, would it make sense to do something like?
    Prefer: time-to-live=0
    or
    Prefer: time-to-live=short (we can have other values like medium, long)

    BTW, this is the first time for me to send a request and discuss something in this mailing list. Please let me know if there is a better communication channel so that I don't pollute everybody's mailbox. 

    Thanks a lot.

Ning

On 9/11/2015 8:06 PM, Matthew Kerwin wrote:
> 
> On 12/09/2015 9:14 AM, "Ning Dong" < <mailto:ning.dong@oracle.com>ning.dong@oracle.com <mailto:ning.dong@oracle.com>> wrote:
> >
> > I submitted two requests, and both of them are related to search. If we have the SEARCH verb, then we don't have this problem.
> >
> > For the case where client wants to execute an ad hoc query against a collection, [...]
> > We don't want to save the query definition though since it won't be useful. We really just want the server to use the query definition in the payload, execute query and return the result.
> >
> > A second use case is a query definition might be reused later, but we want the query to be executed when the query definition resource is created to save a server round trip. That is the return=query-result proposal. This use case is achievable with two requests: one to create the query definition resource, and another to execute the query.
> >
> > Thanks.
> >
> > Ning
> >
> 
> ​ The problem I'm having is that you're mixing things up strangely. The endpoint definition seems to be: POST here to store a procedure. On top of that you layer a preference for "also execute it and return the result." Ok, I can understand that, and maybe 'query-result' is different enough from 'representation' to make sense. But with 'transient' you seem to instead be saying: the endpoint definition is to store a query, and immediately execute it and return the result. On top of that you're layering a preference to not store the query? It seems quite convoluted, or at least not well engineered, and smells a bit like server-side caching of requests. If I'm reading it wrong, and it's actually the *same* endpoint (i.e. store the query, and maybe return an immediate result) then 'transient' isn't a preference, it's an instruction to alter the base behaviour of the endpoint -- an instruction which should be signalled, not with a preference, but with a mechanism like those I mentioned earlier. Cheers