[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [odata] Should we consider positioning OData w.r.t. GraphQL, REST, and RPC?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]