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? 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
