- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 14 Sep 2015 11:01:42 -0700
- To: Ning Dong <ning.dong@oracle.com>
- Cc: Matthew Kerwin <matthew@kerwin.net.au>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Phil Hunt <phil.hunt@oracle.com>
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