Re: NEW PREFERENCE - return=query-result

The "transient" preference looks just fine to me.

On Mon, Sep 14, 2015 at 10:59 AM, Ning Dong <ning.dong@oracle.com> wrote:
> 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" <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
>
>

Received on Monday, 14 September 2015 18:02:30 UTC