Re: NEW PREFERENCE - return=query-result

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