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 Mon, 18 Apr 2016 22:26:00 GMT
BTW, I’ve also added a JIRA [1] for the HTTP API and assigned it to 
Ildar (hope that’s ok - he’s done all the work so far :) ).

Cheers,
Till

[1] https://issues.apache.org/jira/browse/ASTERIXDB-1402

On 18 Apr 2016, at 15:14, Till Westmann wrote:

> Here [1] is one :) But I still think that this is not the first 
> priority.
> Let’s get the basics right first :)
>
> Cheers,
> Till
>
> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1253
>
> On 15 Apr 2016, at 22:35, Mike Carey wrote:
>
>> +1 for the separation and also for providing a place where we can 
>> deliver warnings - I remember longing for a few recently (we might 
>> have one or more JIRA issues mentioning that).....
>>
>> On 4/15/16 8:16 PM, Till Westmann wrote:
>>> Yes, indeed the warning are feature-creep and not essential. We have 
>>> been
>>> talking about compiler warnings for along time, but we don’t have 
>>> them so
>>> far. The warnings that we could show for the HTTP API are warnings 
>>> about
>>> unused or ignored parameters but, again, they are not essential. 
>>> It'll be
>>> perfectly fine to add that at a later time when there's a concrete 
>>> need/use
>>> for them.
>>>
>>> Also, thinking about it a bit more, I'm even more convinced that 
>>> it's the
>>> better approach to have different fields for results and result 
>>> handles as
>>> the client can know if it needs another hop just by looking a the 
>>> response,
>>> without knowing what the request was.
>>>
>>> Cheers,
>>> Till
>>>
>>> On 15 Apr 2016, at 17:32, Ildar Absalyamov wrote:
>>>
>>>> Till,
>>>>
>>>> All the comments make sense to me except for warnings. I was 
>>>> struggling to remember anything in Asterix, which would resemble 
>>>> the warnings described by you.
>>>> As a future extension we could support that, but in this document I 
>>>> was trying to reflect current state of Asterix functionality + some 
>>>> extensions which were on horizon for a long time and are really 
>>>> needed.
>>>>
>>>>> On Apr 15, 2016, at 14:37, Till Westmann <tillw@apache.org> wrote:
>>>>>
>>>>> Hi Ildar,
>>>>>
>>>>> thanks for writing all of this up!
>>>>>
>>>>> A few comments/proposals:
>>>>>
>>>>> - Request:
>>>>>  - For the "format" parameter, I think that it would be nice to 
>>>>> support
>>>>>    both, the parameter and the Accept header, as it’s sometimes 
>>>>> much more
>>>>>    convenient to pass a parameter than a HTTP header. However, I 
>>>>> think that
>>>>>    the HTTP header should override the parameter if they conflict.
>>>>>  - "execute-query" could be renamed to "execute-statement" to be 
>>>>> consistent
>>>>>    with the "statement" parameter.
>>>>> - Response:
>>>>>  - I'm wondering if "results" should be able to get a URI for the 
>>>>> handle or
>>>>>    if we should have another field in the response for that (e.g.
>>>>>    "handle"). The advantage of 2 fields would be that the consumer 
>>>>> knows
>>>>>    how to parse each field (either as a URI or as an array).
>>>>>  - Inside of the "metrics" object I would only expect simple 
>>>>> numbers. For
>>>>>    the plans we could have another top-level field ("plan"?) an 
>>>>> object that
>>>>>    contains the different plans ..
>>>>>  - It would also be nice to add a new top-level field for 
>>>>> warnings. That
>>>>>    could be used to report warnings from the engine that evaluates 
>>>>> the
>>>>>    statement. And it could also be used to report unused 
>>>>> parameters
>>>>>    (assuming that the default behavior for a parameter that is 
>>>>> passed in,
>>>>>    but not understood by the server is simply ignored).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On 14 Apr 2016, at 15:23, Ildar Absalyamov 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
>>>>
>>>> Best regards,
>>>> Ildar

Mime
View raw message