First of all let me tell you what is a Rest and GraphQL !
REST(Representational State Transfer) and GraphQL are two API design styles that serve the same purpose: transferring data over internet protocols including HTTP. However, REST is an architectural pattern, whereas GraphQL is a query language
1) Rest has Multiple End points, where as GraphQL has one endpoint !
2) Both generally give the Data back in JSON format
3) Both are Stateless:
Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. The server never relies on information from previous requests.
4) Rest APIs are more flexible, whereas GraphQL only works with POST !
5) In GraphQL you can be more detailed about the kind of data you want to fetch, but thing is not applicable in REST APIs as it fetches all the data available
6) In REST because of its tendency to pull all the data it brings a huge amount of data which is unnecessary to the client !
In total in my opinion both have their own benefits, if you are new to APIs, then go with REST APIs
If you are running a massive project then go for GraphQL.
Oldest comments (24)
Isn't this just bad API design though?
Yes and no. The alternative is tailored endpoints, which leads to exponential maintenance growth, or an approximation of what GQL already does out of the box. Consumer-declared output structure is an excellent design for general-purpose APIs. GQL has its downsides when it comes to complex nesting, but that is more indicative of bad API design than anything.
Hmm fair enough. I was just thinking about closed source software/websites. There I can easily tailor the endpoints to my needs and know exactly what's requested. Public APIs sure are way different in that aspect though
Nesting is one thing, but for limiting the columns/keys returned, it's simply a matter of passing a query string (for GETS) or a list in the headers (for POST/PUT/PATCH). All REST interfaces should be designed this way. There is no point passing back what isn't required.
You can use query strings to indicate joins, selects from nested elements, etc., too, but this might be past the point of diminishing returns -- and would start to resemble putting GraphQL in the query string. What would be the point?
So which is better depends on your data model, really.
I don't find GQL to be the perfect end-all for more intense scenarios. People tend to forget how easy it is to combine data similar to graphql in postgresql with simply a WITH clause. Processing transactions, subscriptions, notifications, all in a single query if you wanted to do a wallet based subscription.
From my perspective, I just find graphql to be another sign of convenience, a sense of escapism from the raw values of lowish-level relational data management. REST is so easy if you know how to reduce I/O, minimize your mappings, and figure out to reduce the amount of queries, especially when there's math involved.
I'm not against graphql as I've thought about giving it a shot. But I already have PTSD from Symfony/Doctrine's ORM mappings.
On YouTube, maybe Twitch, I'm actually going to be doing a series soon showing my own methodologies on building slightly complex sites, but starting off with simpler ones just to give people ideas whether they're new or experienced.
Can't wait for the series, leave sime links :)
Thanks for the service ;)
Checkout hasura. It creates queries by analyzing your graphql request. So it's generally very efficient
Rest as an architecture is more limiting as a concept, since you work with data representation (eg: customer endpoints can't and shouldn't return supersets for example)
On the other hand, grpc is more flexible (not to mention efficient)
I'd say the biggest benefit of GraphQL is discoverability. It's self documenting. REST APIs are ultimately flexible and hence can be totally different to each other. GraphQL promotes minimal data transfers, and has that principle by default - its highly opinionated about everything which means its much easier to work out what you have access to and how it works. REST apis require you to access the documentation and take pains to optimise the transfers etc. You can certainly write very efficient REST, it's more likely you'll write efficient GQL. When teams have multiple developers then the GQL helps raise the bar in my experience.
With HATEOAS you have discoverability. Without HATEOS, technically you do not have REST.
That's is a very good point that I should have heeded. From my experience HATEOAS implemented REST only tells you about subsequent actions doesn't it? If you need to understand parameters and available actions in a human readable way, then GraphQL is a practical developer friendly system due to it's strong opinions.
GraphQL certainly has its strengths (I've been using it for years now). But most of the people who bash REST have never actually implemented it correctly and don't understand how flexible it can be. Partly, I think, this is because everyone wants a shortcut, like Swagger. I read Roy's thesis twenty years ago and have been trying to do REST correctly ever since, but I get a lot of pushback from other devs who think it's too much work.
One place I worked at set up a team to rewrite their REST interface (a big enterprise). After almost a year, they had little to show for it because the team met once a week and spent all their time arguing. They even had an expert consultant on the team who explained how to do it, but they of course rejected most of what he said. Ironically, at the same time they were adamant that we couldn't implement GraphQL.
I guess we could always go back to RPC...
Having used HTTP based message enqueueing for a long time (basically RPC) we added a RESTish (my new term for what you are describing :]) and a GraphQL interface to our back end data platform. In doing this I've realised that GQL can represent almost anything as an API, which I couldn't really "see" before. If you can jump through the hoops once it really can be used to auto-scaffold, it has clear error messages and a bunch of intellisense logic for IDEs. I'm sold on it for our purpose which is a configurable set of document types where the GQL schema is generated based on the configuration - so there's new stuff to learn regularly.
I'm most impressed by the way we can represent relational data in the schema and therefore in the responses.
Sounds like GraphQL is a good choice for your use case.
Was considering both for a project, but when I found Postgraphile, I don't think I'm going back to Rest, ever.
5) - it is the same for Rest.
GQL is Rest with only a POST request to one route
One of the issues i had with working with graphQL was authentication. In my opinion i believe it is quite easy to implement authentication in REST API than with graphQL. But graphQL certainly makes it fun to build API's compared to REST.
Just incase someone reading this thinks it’s GraphQL or REST it’s totally possible to use both e.g. Apollo-Server-Express. We have to use REST for nearly every external service in our app, along with webhooks.
Even though this is a backend discussion it’s worth mentioning the reward of GraphQL on the Client side e.g. Apollo-Client or URQL where caching is mostly done automatically and writing manual updates is very easy.
We use URQL and if all of our active clients have the data for the views they need, there are zero server calls for n-users unless the window is reloaded or there is a data change, and this pretty much out-of-the-box. GraphQL is a difficult paradigm but overall I am very satisfied using it.
Nice post
Couple things to remember OData and HATEOS are built on REST and support a lot of what people want from GraphQL - also GraphQL is not free, you still usually have limits to what queries you support and such.
You can design rest with a single endpoint that uses the URL for everything etc. If you really want.
Not saying GQL is bad or anything, it just really isn't the silver bullet a lot of people feel it is.
:sigh: why does nobody ever look into other alternatives? There are options out there with the extras you get by default with REST along with the complex querying capability of graphql. Take a look at OData, JSON-LD, HAL, and JSON-API. Probably a few others I have forgotten about.
you can use projection by skip and limit and offset parameterization in the API design to optimize particular endpoints, and use resthooks.org to set up pub/sub (REST+H), distributed computational REST (D+CREST), modal computational REST (McReST lmao), asynchronous REST, delegate REST, estimable REST, etc..
You can use GET with GraphQL as well.