asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron Samak <csa...@apache.org>
Subject Re: New Asterix REST API design
Date Fri, 15 Apr 2016 22:51:55 GMT
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 <csamak@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 <dtabass@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.absalyamov@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
>>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message