RE: [odata] Should we consider positioning OData w.r.t. GraphQL, REST, and RPC?

["Handl, Ralf" <ralf.handl@sap.com>]

I found that GraphQL closely resembles $select and $expand, so it would seem possible to have a GraphQL Query API on top of an OData Service.

Updates seem to be less uniform in GraphQL, the Mutations examples I've seen so far more resemble action imports.

OData entity sets on the other hand have rather uniform CUD behavior, and we have built generic clients that leverage and depend on this uniformity. 

So "OData with Entity Sets" is still rather RESTish and shows its AtomPub origin even now that we've completely moved to JSON.

Of course now one can also literally translate RPC-style APIs into "OData with actions and functions" and completely miss out on the uniformity provided by entity sets.


-----Original Message-----
From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Mr. Stefan Hagen
Sent: Montag, 13. August 2018 11:18
To: odata@lists.oasis-open.org
Subject: [odata] Should we consider positioning OData w.r.t. GraphQL, REST, and RPC?

Dear members,

Just some Monday morning questions ;-)

In preparing a 101 GraphQL talk, I came across 
the following blog article:
https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/

Inside I read:
"""
[...]
Some APIs use also end up with arguments in the 
query string that are not related to filtering, 
more like options. [...] 
In these scenarios, GraphQL beats the pants off 
of REST APIs that try to hand-roll their own query 
language functionality, but I would suggest hand-rolling 
your own query language is a bad idea anyway. 
GraphQL gives you a query language syntax, and SDKs 
for your programming language to fetch the right models 
for that, but so do things like OData, a project with 
the slogan "A Better Way to REST".

This is another example of folks saying that REST cannot 
do something, just because many REST APIs don't do it, 
or because its implemented poorly by many that do. 
Saying that, remember that the more customisation an 
endpoint-based API adds to the request, the fewer cache 
hits are likely at a network caching level, making the 
REST/HTTP approach less rewarding, and forcing you down 
the route of the application caching and database 
reorganisation that GraphQL forces anyway.

If your API is highly customizable, it's another 
ticked box for considering GraphQL.
"""

Question:
What is our position on statements like these 
and should we re-consider and update our base 
technology statements?

Points taken: 

We still are quite RPCish with version evolution, right?

We have a grammar for the URL conventions, but inherit 
the when is what a function / query parameter, a request header
(at least implementer do not always see clear placement
directives from our specs), right?

Would adaptive requests be easier, if we say 
in a POST mode would allow to send field templates 
to the endpoint as a seamless transition to a GraphQL
like API concept?

Could we already have a GraphQL server answering OData requests
in a conforming way?


All the best,
Stefan