GraphQL-API | A Basic GraphQL API for Books | GraphQL library

Let's break this down a little, because you may have accidentally asked a lot of questions that aren't easily answered in a short single paragraph :)

First of all, what makes a REST API?

REST API's use a subset of HTTP methods and the protocol itself to transfer API data and transmit changes to an API. In other words, it's a client-server protocol which operates using the parameters of an endpoint, a method, the headers, and a body and/or query parameters. It's constrained to be stateless, meaning that we must be able to send any call at any time, simply speaking.

We have several HTTP methods in use to get data, update data, create data, and delete data. However, there's no strict standard beyond this that's enforced to define how these endpoints are structured or how they behave. There are some loose rules however.

It's common to compare REST to GraphQL, however, this comparison isn't always going to make sense, as we're just comparing two approaches (out of many) to create APIs, but aren't comparing apples to apples. GraphQL is a specification that creates a new form of typed, stateless, relational API which is more akin to REST together with JSON schemas and Swagger.

But, what about GraphQL?

GraphQL over HTTP is actually seemingly comparable to REST APIs, but in actuality it's just GraphQL queries being executed against a GraphQL schema that happens to be accessible via an HTTP endpoint. It's however not restricted to HTTP. This is where we can start to see the differences. REST may also be an approach, but it's become a common method to build out an HTTP API. GraphQL is a schema language, query language, and API system that isn't strictly speaking constrained to HTTP. Hence, it can't be REST-compliant. (However, do look into "Persisted Queries" and "Automatic Persisted Queries" to see how we can still use HTTP CDNs)

The closest approximation to a GraphQL over HTTP API is actually not REST, surprisingly. It's SOAP APIs, aka the Simple Objects Access Protocol from 1998. That's because SOAP also focuses on exchanging structured information.

GraphQL is very advantageous at modelling relational data and giving us an API that can freely be constructed to access relational nodes. It defines a schema language that defines the types and other constraints of the executable schema (which is also separated into modify/query, so not dissimilar to REST methods), and a query language using which we can traverse this schema graph.

Lastly, asking for an alternative here is hard. A lot of time has gone into GraphQL, and while I'm aware of some smaller alternatives, none are as popular. It's important here to note that GraphQL is just a specification, when you take everything else away. Hence, it isn't important to find "alternatives" because there are several implementations of it and it builds an ecosystem. In other words, it's adopted beyond just Facebook and this wide adoption helps community tooling.