OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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:

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.

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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]