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 <[email protected]>
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
