I think the reason why graphql is currently winning is tooling. GraphiQL, schema-aware+caching clients for front end frameworks and fragments are all things tha

I think the reason why graphql is currently winning is tooling. GraphiQL, schema-aware+caching clients for front end frameworks and fragments are all things that could exist for OData or JSON-API or whatnot, but i don‘t think they do. Ember has something nice for JSON-API I believe, and you can generate various clients from your Swagger spec, but It doesn‘t look like the same thing. It‘s not great that paging, sorting and filtering aren‘t speced in graphql, so something better could be appealing. If OData had something along the lines of urql graphcache and a good pattern for composing 1 screen query from component fragments I‘d be interested, but I‘m not going to write it. Also, as people like to point out, GraphQL is really some kind of RPC, which is actually pretty handy. Most ad hoc HTTP api‘s are as.well, but once you enter a more well defined spec, do you still have that flexibility to just "get things done"?