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.
Latest comments (24)
You can use GET with GraphQL as well.
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..
: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.
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.
Nice post
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.
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.
5) - it is the same for Rest.
GQL is Rest with only a POST request to one route
Was considering both for a project, but when I found Postgraphile, I don't think I'm going back to Rest, ever.
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.