Menu
I have used OData in my career quite a bit and now few of my colleagues from different teams recommended we move to JsonAPI and GraphQL as its not tied to Microsoft. I don't have much experience in both these query languages. As far as i know OData is a standard used by Salesforce, IBM, Microsoft and it is very mature. Why should one switch to JsonAPI and/or GraphQL? Is there a real benefit? Is JsonAPI and GraphQL new standard? Changing public api implementations based on popularity seems useless especially when there is no big benefit.
Can someone please enlighten me?
552
OData is basically a standard that defines the best practices for the user for building and consuming the restAPIs. GraphQL is like a programming language, a query language that is used to fulfill those queries with the complete understanding of data in your API.
REST stands for REpresentational State Transfer which is a resource based architectural style. Resource based means that data and functionalities are considered as resources. OData is a web based protocol that defines a set of best practices for building and consuming RESTful web services.
OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc.
That being said, both GraphQL and JSON:API are compatible with REST, and while the Venn Diagram of offerings that are “REST and also GraphQL” is not 100% (and neither is the case with JSON:API), the tooling and community is still very large.
OData is a similar specification to JSON API. Both of them describe a standard protocol for creation and consumption of RESTful APIs. GraphQL is a totally different approach to API design and specifies a different way of querying API resources.
OData: Designed and developed at Microsoft since 2007, standardized by the OASIS consortium. The latest version V4 is submitted to ISO/IEC JTC 1 for approval as an international standard. Companies on the technical committee (TC) include CA Technologies, Citrix, IBM, Microsoft, Progress, Red Hat, SAP and SDL.
There are a number of libraries for popular programming languages - .NET, Java, JavaScript, PHP and Ruby. The spec allows dynamic resources and there's a service document which lists all API endpoints for clients to discover. Additionally, there's a metadata document describing the schema.
JSON API: JSON API was originally drafted by Yehuda Katz in May 2013. This first draft was extracted from the JSON transport implicitly defined by Ember Data’s REST adapter. The current stable version of the spec is 1.0. The JSON API spec is implemented for the majority of programming languages, for both the client and server sides.
JSON API supports HATEOAS through the link property in the JSON document. Other features include pagination, sorting, filtering and relationships. The JSON documents produced by JSON API servers are very verbose with lots of nested properties.
GraphQL: Developed at Facebook since 2015. The specification is still a working draft. It's quite popular among React fans and is mainly used in combination with React or Vue.js. Similar to GraphQL is Falcor, which is also relatively new.
While GraphQL makes use of HTTP, it is not considered REST, rather, an alternative to REST. Instead it makes use of a query/response model into a single (virtual) JSON document. This new model is somewhat nicer for developers to work with, but its benefits over REST are debatable. Given its young age, the ecosystem has yet to mature.
For the sake of clarity and completeness, I’ll include OpenAPI to the list, although it is not exactly an API specification. That can be confusing to some people. The OpenAPI standard is a language-agnostic standard for describing and defining APIs. Your API can follow one of the above standards (excluding GraphQL) and also be documented using OpenAPI 3, for example.
The best thing you get with specs like OpenAPI is the tooling around them - generators for API documentation pages, generators for client SDK code, etc.
This standard is probably the most commonly used today for API declaration, documentation and code generation. It is also supported by cloud providers like Amazon Web Services in their API Gateway.
In summary, OData and JSON API are both JSON data formats which add context and features (e.g. links) around your data, GraphQL is a totally different new way to query and mutate JSON data, and OpenAPI is the standard way to declare and document any RESTful API.
My personal opinion:
As you can see, there are quite a few RESTful specs out there, rather than a single universal standard. I agree with xumix here - they all seem to suffer from the "Not Invented Here" syndrome. The benefits of choosing any of the above are small, especially if your project is small or medium sized. Does it matter which specification your API implements? Probably not much. Just focus on building a consistent and well-documented API.
197
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
