+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
