Meet one of the well-known oppositions in the world of API development: GraphQL vs REST.
GraphQL and REST are both popular API design standards with different histories and not quite in line with each other at present. They are certainly not equivalent nor interchangeable, and they both have their avid supporters and opponents among very experienced as well as junior software developers.
The answer to the question which one is better is, of course: well, it depends.
Trying to figure it out is equally pointless as deliberating on which came first: the chicken or the egg? ;) But it’s good to outline what they are exactly, learn the differences between them, as well as determine who should use them and when to their greatest advantage depending on the project type. And that’s just what we’re going to do in this blog post.
Table of contents:
1. REST vs GraphQL – the lowdown
2. GraphQL – who should consider using it?
3. REST – why it’s still most developers’ favorite
4. GraphQL vs REST API wrapped up
GraphQL vs REST – the lowdown
Now it’s time to introduce the main subjects of this article, and we’ll start taking seniority into account.
REST - the API design legend
Undoubtedly, it’s REST that is a true legend that’s been used immensely for over two decades and we can say that it's quite the industry standard. Since its beginnings that date back to 2000, REST (name abbreviated from Representational State Transfer and made for distributed hypermedia systems) has provided a set of guidelines for designing and developing the architecture for the Web.
REST is something that defines what resources are and how to access them, and API – standing for Application Programming Interfaces – is what makes access to those resources possible. And according to the REST architectural style originator Roy Fielding, resource means any piece of information that can be named.
PS For more info on Roy Fielding himself, you can check out his Wikipedia bio.
GraphQL - the most recent mainstream alternative to REST
However, the times when REST managed to gain this dominant position were very different from what we may observe today, when communication needs are way more complex, and when there’s a need for speed and diversity. And now, GraphQL is gaining popularity and attention due to its flexibility, modernity, efficiency, and swiftness (often much more impressive than those of REST).
In detail, according to its website, GraphQL is „a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools”.
Interestingly, GraphQL’s public release took place in 2015, although it was developed internally by Facebook in 2012 (you can read more about it on GraphQL's Wikipedia). A few years later, GraphQL was called the most mature alternative to REST.
GraphQL – who should consider using it?
Who should consider using GraphQL, then?
A GraphQL API will be a good choice when you’re trying to solve the over-fetching or under-fetching problem, and, for some reason, query parameters are not enough and won’t do. It may also be a good choice when you’re building an API that will be consumed only by the web service end user and not other services in the microservice architecture.
GraphQL is also distinguished by the simplicity of use for the client, as well as its „additional complexity on the server”. On top of that, Codegram calls GraphQL „a declarative and hierarchal way to fetch data, with just one endpoint to rule them all”. And single endpoints from which clients fetch data in response to any API request to the server is certainly a plus.
Other benefits of GraphQL APIs include: scalability, efficiency, and easy error handling. That's a few reasons why it is often chosen for microservices. And, because it is suitable for quick iteration cycles, it’s also good for many use cases that adapt Agile approaches like Scrum.
REST – why it’s still most developers’ favorite
But REST APIs are certainly not out of competition, yet.
In general, this simple and easy-to-start-with classic API standard is OK if you don’t want to reinvent the wheel with request options and error codes. It may also be more proper when you want your API to be generic instead of adapted or tailored to particular use cases. Also, because this technology is more popular, and more developers are working with it, it’s easier to get access to this developer experience pool and pick somebody skilled and seasoned enough in case you need more information on best practices or help with solving particular problems.
There are some constraints, though, and the most serious one is related to the scale of the project. The REST architecture may simply be hard to manage as the architecture gets bigger and more complex.
GraphQL vs REST API wrapped up
While it’s impossible to clearly indicate which part of the REST API vs GraphQL opposition is superior, we may say what needs those particular API design standards will be the best for.
Pros, cons & use cases of REST and GraphQL
REST may be very handy in many cases as no initialization or libraries are needed for pros who work with someone else’s API. And GraphQL may turn out to be better in the case of more complex projects and architecture. Besides, it offers features that are not available via REST – through numerous open-source GraphQL extensions.
But GraphQL is not an answer to every issue, and REST – simple and easy to start with – still has its role to play. And let’s not forget that GraphQL REST is not the only opposition here as there are more modern REST substitutes in the API design standards category. Some of the most interesting GraphQL alternatives include, for example: FALCOR, JSON-Pure, WebSocket, SOAP, and RPC (you can read more about SOAP and RPC in Fernando Doglio's article).
And which API design standard do you prefer for your projects? Is REST still the first choice for you? In turn, who should consider using GraphQL? Is there any other API design standard you’d recommend to API developers?
