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
