Re: NEW PREFERENCE - return=query-result

[Ning Dong <[e-mail]>]

Hi,
   Is there more information that I should provide to get the proposed preference added?

   Besides sending email to this mailing list, do I need to do something else?


   Thanks.

Ning

On 9/14/2015 11:01 AM, James M Snell wrote:
> The "transient" preference looks just fine to me.
> 
> On Mon, Sep 14, 2015 at 10:59 AM, Ning Dong <[e-mail]> 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" <[e-mail]> 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
>> 
>>