Disregard the comment about the example 2 /result not being lossless. The last time I used the lossless API was when there was no wrapper array by default - I assumed it was still that way.
This also partly invalidates the question about the parameter name, although I still think a more descriptive name (e.g. include-adm-type, but something better :)) is worth considering. Thanks, Cameron On Fri, Apr 15, 2016 at 3:33 PM, Cameron Samak <csa...@apache.org> 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. > > 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. > > 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 <dtab...@gmail.com> 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 < >>>> ildar.absalya...@gmail.com> 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 >>>> >>> >> >
