REST API OR GraphQL

Why not both?

What I have to say is especially applicable in situations where your consumers need to make calls to more than one service for a single purpose. But still applicable in all cases where you're needing to retrieve data from different resources for any consumer - even if those resources' endpoints live in the same service.

We've all seen 'REST' APIs with endpoints like /accountPageData that do a collection of things, compiling information about a bunch of different resources and throwing the resulting response at the client.

And if you haven't seen that, you've definitely seen chains of promises in the frontend to handle making calls to multiple endpoints to collect all of the data you need for a page or component.

In either case, an alternative approach is to build a nice, clean RESTful API that doesn't contain any of the resource combining BS I wrote about earlier. Then adding a GraphQL layer between that API and your consumer(s). This means your APIs stay RESTful and your consumer(s) can ask for whatever bespoke data combinations they want without polluting your pristine APIs.

Overall an approach like this is a teaser to the world of Backends For Frontends or BFFs.

Having said all of that, my typical advice when it's early in development is to build with REST until it starts hurting or getting ugly. At which point, consider a simple BFF layer to keep your APIs clean and your frontend developers sane.

As the others said, it depends on requirements and needs.

Taking from GraphQL vs REST: Overview:

• Most of us don't do REST, we do RESTish (the hypermedia part is left out in many, many, APIs, mine included)
• If you are not using hypermedia then GraphQL is a good alternative
• File uploading is easier in REST than in GraphQL
• Deprecation is easier in GraphQL
• GraphQL is better for asking only a subset of a full resource (because you can ask only the fields you need)
• REST plays better with caching at all levels (proxies and all). GraphQL transfers caching to the client and cannot use HTTP caching headers.
• GraphQL is better at introspection (you don't have to design the schema of the API, it's implicit in the definition)
• Filtering is hard in both
• Sending different responses for different clients is way easier in GraphQL (which is one of the reasons Github migrated to it)

I don't think they can be pitted against in every case, it really depends on what you need. You can also use both as it's suggested in the article :)

I feel that most devs are misusing GraphQL and what they really should be using is the JSON API specs for their REST API. It offers most of the features that people are looking for when migrating to GraphQL.

That said; I think probably 80% of devs only use GraphQL for Relay and not as a standalone/public API.

I've liked working with GraphQL recently, it can be a very powerful tool if you know what you're building.

REST is of course more standard and more people are familiar with it. To that end, it depends on who's going to be consuming it.

It really depends on how you expect the data to be used. If unsure I'd go REST to be more standard.

There are specific times where Graphql is much better than REST like APIs. By default I would stick with REST style APIs unless you have a specific reason to use GraphQL. GraphQL is better for Facebook, but for most apps it's adding a lot of complexity. I remember a long time ago being really excited about ORMs like hibernate and how simple they made database access. Nowadays I'm also appreciating the simplicity of using SQL when writing non CRUD database operations (bulk ops and reports, for example). The ORM hides complexity, but also obscures performance issues. GraphQL is like that. It moves complexity around, and this could be the right move for you, but I think most of the time you might as well safe yourself the code bloat.

I've never used GraphQL, but if I was starting a project I'd use it because it looks cool af.