On 15 Apr 2016, at 15:33, Cameron Samak wrote:
Thanks, this page is very clear. Some thoughts:
Maybe there should be a way to request only the results in the body?
It
seems that CSV within JSON at least partially defeats the purpose of
requesting CSV in the first place.
I think that’s what you’d get from the "result" endpoint (however,
after
a hop …).
Thoughts on also allowing formatting options with the /result
endpoint? For
example, I think it makes sense to allow choosing "lossless" in
example 7
during the /result GET instead of /query.
That’s not that easy as the serialization to the desired format is
done by
the result distribution framework that runs on all NCs. So by the time
that result is picked up by the HTTP server, that decision is already
taken.
Am I correct that /result example 2 is showing "lossless=false"
results
instead of "lossless=true" as requested in example 7? Related: Could
the
"lossless" parameter have a more descriptive name? Without context
surrounding the originating discussion the parameter name doesn't seem
to
make much sense for a user expecting valid JSON.
Also I think this page is also a good place to add possible HTTP
response
codes and when they apply.
Cameron
On Fri, Apr 15, 2016 at 2:55 PM, Mike Carey <[email protected]> wrote:
I read this much more simply: Can we enhance the API, in the case
where
you start with a handle and know that the results are ready now, to
fetch
the results in blocks instead of as one giant result? So still
computing
the giant result - just not pushing it all back at once - seems like
it
might help?
On 4/15/16 2:48 PM, Till Westmann wrote:
Hi Wail,
I’m not completely sure that I understand how to implement the
idea. If we
do this only in the API, it might be tricky to get the boundaries
between
records right (e.g. if we do indentation on the server). However, if
we
want
to push this into the query engine, we need to understand enough of
the
query/statements to put the limit clause in.
Both approaches don't look great to me.
What did you have in mind?
Cheers,
Till
On 15 Apr 2016, at 13:19, Wail Alkowaileet wrote:
Hi Ildar,
I think if there's something I would love to have is getting
partial
result
instead of all result at once. This can be beneficial for result
pagination. When I use AsterixDB UI, 50% of the time my tab crashes
(I
forget to limit the result).
Thanks...
On Fri, Apr 15, 2016 at 1:23 AM, Ildar Absalyamov <
[email protected]> wrote:
Hi Devs,
Recently there have been a number of conversations about the
future of
our
REST (aka HTTP) API. I summarized these discussions in an outline
of the
new API design:
https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design
<
https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design
.
The need to refactor existing API came from different directions
(and
from
different people), and is explained in motivation section. Thus I
believe
it’s about the time to take an effort and improve existing API,
so that
it
will not drag us down in the future. However during the transition
step
I
believe it would be better to keep exiting API endpoints, so that
we
would
not break people’s current experimental setup.
It would be good to know feedback from the folks, who have been
contributing to that part of the systems recently.
Best regards,
Ildar
--
*Regards,*
Wail Alkowaileet
