Hacker News Reader

Comment by ako | Hacker News Reader

What is wrong with Odata?

Odata v4 with json payloads is more or less how most would define the payload manually, it has all the benefits of GraphQL (retrieving a tree of objects, selecting required attributes), is fully compatible with Rest (retrieves are GETs, mutations can be POST, PUT, DELETE), has a true query language with filtering, aggregations, expressions, joins, paging, sorting, which are all part of the url so you can cache it like a normal Rest GET, has batches so you can update multiple objects in one transactions, and supports subscriptions so you can receive updates instantaniously...

View on HN

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"?

I evaluated GraphQL for a Django back end project this week. We currently use Django Rest Framework. I also explored the current REST landscape and OData came up.

I understand why OData isn't seen more.

For example compare graphql.org www.odata.org. It's a huge difference. The GraphQL landing page is up front on what it does and how it can help you. OData has this:

> OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs.

What is this supposed to tell me? To me it doesn't sound like OData is a committee based REST api and that's not a pro in my book.

There were other things that led me to not consider it as a viable option: - the OData format doesn't look clean and nice, OData fields and function calls - the framework support in python is practically nonexistent

And I still don't know which problems it actually tries to solve. If you could tell me, I'm more than happy to listen.

It's a standardized way of doing Rest. Has most of the performance benefits of GraphQL (improve performance by reducing roundtrips and flexible way of specifying what objects and attributes you need), and then some. See examples on this page: https://www.odata.org/getting-started/basic-tutorial/

You can use Rest resources like database tables, with filtering, sorting, paging, do RPC style requests like GraphQL with Odata actions, or do data replication with odata subscriptions.

Biggest benefits to me are: 1) is a Rest protocol, instead of something on top of Http like Soap or GraphQL, 2) sql like resource access helps random access to data in different apps using standard reporting tooling like Excel and PowerBi, and 3) rich metadata which helps clients understand what they can do with the Odata resource (filterable, sortable, pageable, countable, etc).

Thanks for you short explanation.

I’ve only played with a a bit of ODATA but it seems quite under appreciated. I think I’ve only seen it in (some of) Microsoft’s APIs.

The main problem was that it was invented by Microsoft.

Reply on news.ycombinator.com