asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <ti...@apache.org>
Subject Re: New Asterix REST API design
Date Fri, 15 Apr 2016 21:55:00 GMT
Not completely. There are a number of parameters for the N1QL API that 
are
quite specific to the query evaluation in Couchbase. On the other hand 
there
are a number of parameters in Ildar’s document, that are specific to
AsterixDB (e.g. the aync execution mode :) ). So while there’d be a 
big
overlap between the APIs wrt. the structure and content of the APIs 
neither
one would subsume the other one. To make life easy for clients, we 
should
also say, that unsupported parameters are simply ignored (and 
potentially
warned about), but that they would not cause errors.

Does that make sense?

Cheers,
Till

On 15 Apr 2016, at 14:11, Ian Maxon wrote:

> It seems to me like this new API would be a superset of the N1QL API,
> right?
>
> On Fri, Apr 15, 2016 at 1:19 PM, Wail Alkowaileet <wael.y.k@gmail.com>
> 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
View raw message