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