You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vxquery.apache.org by Preston Carman <pr...@apache.org> on 2017/06/06 20:03:02 UTC
VXQuery RESTful API Review?
Do we need to review our RESTful API [1]? Recently, AsterixDB has
published their API [2] with the latest release. The AsterixDB wiki
has more details about the API specifics [3]. As we are trying to
align with the AsterixDB project, I am wondering how outdated our
RESTful API is based on recent changes to AsterixDB.
As I understand our API, we are using a combination of AsterixDB's
Query and Asynchronous Result APIs. Is there anything else we need to
support?
[1] https://cwiki.apache.org/confluence/display/VXQUERY/Server+API
[2] http://asterixdb.apache.org/docs/0.9.1/api.html
[3] https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design
Re: VXQuery RESTful API Review?
Posted by Till Westmann <ti...@apache.org>.
Hmm, I think that there should be no result wrapper.
In the proposal in [1], I think that we were redundant in returning the
result metadata (which is already returned by the the first request to
the
/query endpoint) with the actual result. I’d prefer (and I assumed
this in
my first reply even though that’s not what we wrote in [1]) that we
first
return just the metadata with the result URL (in the format chosen by
the
client - JSON or XML) and then get the "pure" result from the
/query/result
endpoint. In that case the result would be JSON or XML (or an error if
the
accept header does not allow for the format returned by the query.
Thoughts?
Cheers,
Till
On 7 Jun 2017, at 21:29, Preston Carman wrote:
> The query defines the format of the result. I can write a query to
> produce XML or JSON. As for the RESTful API format the results are
> returned, I think your referring to the result wrapper. The wrapper
> could be formatted in either JSON or XML with the query result being a
> string in an element or object field. Since the query defines the
> result format, it seems unconnected to the RESTful API response
> format. An interesting dynamic with the wrapper and the query result.
>
> On Wed, Jun 7, 2017 at 7:26 AM, Michael Carey <mj...@ics.uci.edu>
> wrote:
>> +1 for both result formats now!
>>
>>
>>
>> On 6/6/17 10:00 PM, Till Westmann wrote:
>>>
>>> I think that the API still looks pretty good. A few considerations:
>>>
>>> - We could think about an async API similar to the one in AsterixDB,
>>> but I
>>> don’t think that that should be a priority.
>>> - A point that I might want to change is that we return a result id
>>> and a
>>> URL - it seems that the URL is sufficient.
>>> - On addition that we should consider - now that we also support the
>>> JSONiq
>>> extension - is some support for returning results in XML or in
>>> JSON. I
>>> think that a good way of implementing this would be to support the
>>> Accept
>>> header for the query and the result endpoints. For the query
>>> endpoint
>>> the
>>> result structure could they either be returned as JSON or as XML
>>> (both
>>> should always be possible) and for the result endpoint we could
>>> return
>>> either XML or JSON (if the Accept header allows it) or an error.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Till
>>>
>>> On 6 Jun 2017, at 13:03, Preston Carman wrote:
>>>
>>>> Do we need to review our RESTful API [1]? Recently, AsterixDB has
>>>> published their API [2] with the latest release. The AsterixDB wiki
>>>> has more details about the API specifics [3]. As we are trying to
>>>> align with the AsterixDB project, I am wondering how outdated our
>>>> RESTful API is based on recent changes to AsterixDB.
>>>>
>>>> As I understand our API, we are using a combination of AsterixDB's
>>>> Query and Asynchronous Result APIs. Is there anything else we need
>>>> to
>>>> support?
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/VXQUERY/Server+API
>>>> [2] http://asterixdb.apache.org/docs/0.9.1/api.html
>>>> [3]
>>>> https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design
>>
>>
Re: VXQuery RESTful API Review?
Posted by Preston Carman <pr...@apache.org>.
The query defines the format of the result. I can write a query to
produce XML or JSON. As for the RESTful API format the results are
returned, I think your referring to the result wrapper. The wrapper
could be formatted in either JSON or XML with the query result being a
string in an element or object field. Since the query defines the
result format, it seems unconnected to the RESTful API response
format. An interesting dynamic with the wrapper and the query result.
On Wed, Jun 7, 2017 at 7:26 AM, Michael Carey <mj...@ics.uci.edu> wrote:
> +1 for both result formats now!
>
>
>
> On 6/6/17 10:00 PM, Till Westmann wrote:
>>
>> I think that the API still looks pretty good. A few considerations:
>>
>> - We could think about an async API similar to the one in AsterixDB, but I
>> don’t think that that should be a priority.
>> - A point that I might want to change is that we return a result id and a
>> URL - it seems that the URL is sufficient.
>> - On addition that we should consider - now that we also support the
>> JSONiq
>> extension - is some support for returning results in XML or in JSON. I
>> think that a good way of implementing this would be to support the
>> Accept
>> header for the query and the result endpoints. For the query endpoint
>> the
>> result structure could they either be returned as JSON or as XML (both
>> should always be possible) and for the result endpoint we could return
>> either XML or JSON (if the Accept header allows it) or an error.
>>
>> Thoughts?
>>
>> Cheers,
>> Till
>>
>> On 6 Jun 2017, at 13:03, Preston Carman wrote:
>>
>>> Do we need to review our RESTful API [1]? Recently, AsterixDB has
>>> published their API [2] with the latest release. The AsterixDB wiki
>>> has more details about the API specifics [3]. As we are trying to
>>> align with the AsterixDB project, I am wondering how outdated our
>>> RESTful API is based on recent changes to AsterixDB.
>>>
>>> As I understand our API, we are using a combination of AsterixDB's
>>> Query and Asynchronous Result APIs. Is there anything else we need to
>>> support?
>>>
>>> [1] https://cwiki.apache.org/confluence/display/VXQUERY/Server+API
>>> [2] http://asterixdb.apache.org/docs/0.9.1/api.html
>>> [3]
>>> https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design
>
>
Re: VXQuery RESTful API Review?
Posted by Michael Carey <mj...@ics.uci.edu>.
+1 for both result formats now!
On 6/6/17 10:00 PM, Till Westmann wrote:
> I think that the API still looks pretty good. A few considerations:
>
> - We could think about an async API similar to the one in AsterixDB,
> but I
> don’t think that that should be a priority.
> - A point that I might want to change is that we return a result id and a
> URL - it seems that the URL is sufficient.
> - On addition that we should consider - now that we also support the
> JSONiq
> extension - is some support for returning results in XML or in JSON. I
> think that a good way of implementing this would be to support the
> Accept
> header for the query and the result endpoints. For the query
> endpoint the
> result structure could they either be returned as JSON or as XML (both
> should always be possible) and for the result endpoint we could return
> either XML or JSON (if the Accept header allows it) or an error.
>
> Thoughts?
>
> Cheers,
> Till
>
> On 6 Jun 2017, at 13:03, Preston Carman wrote:
>
>> Do we need to review our RESTful API [1]? Recently, AsterixDB has
>> published their API [2] with the latest release. The AsterixDB wiki
>> has more details about the API specifics [3]. As we are trying to
>> align with the AsterixDB project, I am wondering how outdated our
>> RESTful API is based on recent changes to AsterixDB.
>>
>> As I understand our API, we are using a combination of AsterixDB's
>> Query and Asynchronous Result APIs. Is there anything else we need to
>> support?
>>
>> [1] https://cwiki.apache.org/confluence/display/VXQUERY/Server+API
>> [2] http://asterixdb.apache.org/docs/0.9.1/api.html
>> [3]
>> https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design
Re: VXQuery RESTful API Review?
Posted by Till Westmann <ti...@apache.org>.
I think that the API still looks pretty good. A few considerations:
- We could think about an async API similar to the one in AsterixDB, but
I
don’t think that that should be a priority.
- A point that I might want to change is that we return a result id and
a
URL - it seems that the URL is sufficient.
- On addition that we should consider - now that we also support the
JSONiq
extension - is some support for returning results in XML or in JSON.
I
think that a good way of implementing this would be to support the
Accept
header for the query and the result endpoints. For the query endpoint
the
result structure could they either be returned as JSON or as XML
(both
should always be possible) and for the result endpoint we could
return
either XML or JSON (if the Accept header allows it) or an error.
Thoughts?
Cheers,
Till
On 6 Jun 2017, at 13:03, Preston Carman wrote:
> Do we need to review our RESTful API [1]? Recently, AsterixDB has
> published their API [2] with the latest release. The AsterixDB wiki
> has more details about the API specifics [3]. As we are trying to
> align with the AsterixDB project, I am wondering how outdated our
> RESTful API is based on recent changes to AsterixDB.
>
> As I understand our API, we are using a combination of AsterixDB's
> Query and Asynchronous Result APIs. Is there anything else we need to
> support?
>
> [1] https://cwiki.apache.org/confluence/display/VXQUERY/Server+API
> [2] http://asterixdb.apache.org/docs/0.9.1/api.html
> [3]
> https://cwiki.apache.org/confluence/display/ASTERIXDB/New+HTTP+API+Design