Hi Ralf
On 13/02/14 17:26, Handl, Ralf wrote:
Hi Sergey,
OData already supports this using the HTTP headers odata.version and
odata.maxversion, see
http://docs.oasis-open.org/odata/odata/v4.0/cos01/part1-protocol/odata-v4.0-cos01-part1-protocol.html#_The_OData-Version_Header.
A server that only accepts the OData query language but does not support OData
JSON can respond with Content-Type:application/json and its own JSON dialect as
long as it doesn't claim to be an OData service by also including an
odata-version response header.
A server that supports both OData JSON and some other JSON dialect can serve
OData clients as well as non-OData clients: the OData clients SHOULD include an
odata-version or odata-maxversion header in their request.
A server that supports only OData JSON will respond with OData JSON, which
after all is just JSON, so non-OData clients can digest it with JSON.parse or
something similar.
And OData JSON in its "minimal metadata" or "no metadata" flavor looks pretty much like
what someone would hand-craft: if a book has an id, the JSON object for a book will have an id name-value
pair. Not much choice there. If you want to return a list of books, that's essentially an array of book
objects. Given that an array as the root object of a JSON document is vulnerable to attacks
(http://haacked.com/archive/2009/06/25/json-hijacking.aspx/), format designers are well advised to make the
array a name-value pair of a wrapping plain object. Now the only design choice left is how to name the array.
OData opted for "value", which seems pretty neutral.
Does that cover your use case?
It really does; it's perfect,
Thanks for the clarifications
Cheers, Sergey
Thanks!
--Ralf
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Thursday, 13. February 2014 17:43
To: [email protected]
Subject: [OT] Is OData open enough ?
Hi All,
Now that CXF supporta OData $filter expressions with the help of Olingo,
I've started wondering, after checking OData 4.0, are we really going
for supporting 'OData the query language' to let CXF developers enhance
the search capabilities of their existing applications not specifically
written with 'OData the protocol' in mind or do we basically add one
more CXF search extension (fine with me per se) which will let users
'borrow' the OData $filter syntax ?
For example, suppose we have a service returning a collection of Books -
this is all formatted in whatever format supported by the application,
example, "application/xml":
GET /mybooks
Accept: application/xml
<Books>
<Book id="1"/>
<Book id="2"/>
</Books>
Now the users liked a $filter syntax and would like support the
filtering of books by id,
GET /mybooks$filter=id%20eq%201
Accept: application/xml
returns
<Books>
<Book id="1"/>
</Books>
; the same for application/json
may be I've got confused but it appears to me that it is really
supported by the formal document ?
Example,
GET /mybooks$filter=id%20eq%201
Accept: application/json
is presumably expected to return JSON formatted per the OData rules *only* ?
I'd really prefer the document:
- making some 'space' between the actual query language and the protocol
itself so that people can apply the OData the query language to their
existing applications without having to re-write them to be OData centric
- this might be supported via $format query, but I'm not sure, I;d
rather see something like
GET /mybooks$filter=id%20eq%201
Accept: application/odata+json
indicating that OData-centric JSON payload is expected back.
Simply
Accept: application/json;format=odata
would probably do too
is it already possible ?
IMHO, the lesser the binding of the language to the protocol is the
better it is for the adopters
Thanks, Sergey
