GraphQL alternative in standard REST JSON API technologies

Question

What exact or close alternative to Facebook's GraphQL?

There is some article that give drawback of GraphQL (being pro are con):

1. https://www.imaginarycloud.com/blog/graphql-vs-rest/
2. https://blog.logrocket.com/why-you-shouldnt-use-graphql/
3. https://www.robinwieruch.de/why-graphql-advantages-disadvantages-alternatives
4. https://www.moesif.com/blog/technical/graphql/REST-vs-GraphQL-APIs-the-good-the-bad-the-ugly/

mainly it is not (yet) industry standard as REST

How to get functionality present in GraphQL using REST, JSON API other libraries?

Particularly for only query part are there similar query languages?

---

This question is not whether GraphQL good or bad, but what is closest approximation with REST. Someone, who knows deeply both GraphQL and REST ecosystem, can draw parallels. Thanks

Answer 1

Let's start by what GraphQL is, as this probably takes less time:

GraphQL is a query language, similar to SQL for databases, to tell a server what fields/elements/properties a client is interested to receive from a server. Similar to SOAP i.e. it uses a single endpoint that either accepts POST or GET requests. Besides GraphQL, you also have RestQL and Falcor that more or less push into the same direction.

In a REST architecture there are only resources. The current resource' state is expressed in a negotiated representation format both, sender and receiver, understand, hence REpresentational State Transfer or REST for short. REST comes with a handful of constraints that when adhered to should guarantee interoperability while allowing the server to evolve in future without having to fear breaking clients, as each participant in that architecture will operate on standardized formats known rather than propretary stuff that is specific to that one API.

While REST often uses HTTP as its transport layer, plenty of questions targeting REST actually ask for HTTP stuff and therefore confuse the two. REST by design is transport layer agnostic and therefore could use other transport protocols other than HTTP as well. Jim Webber gave a great talk back in 2011 where he stated that HTTP is just an application protocol whose domain is the transfer of documents over a network. So, if you make a request in your browser or any other (generic) HTTP client, you just send a single document to the server and get a document as respone. This is HTTP. It just sends documents. The operation of HTTP are tailor-made for this purpose. We still use HTTP to derive business rules off of that document managment. Hence any business rules we conclude are just side-effects of the actual document management.

Neither HTTP nor REST do really care what a resource express. Fielding even claims that REST shouldn't have typed resources. If you compare that to the Web where you use the same client (browser) to look up the current stock exchange, gather information on your favorite car model or the weather forcast for the next couple of days. All of these information are expressed in the same media type, HTML, and still we humans can make sense of it as browser are good in rendering such a payload on the canvas so we don't have to deal with this SGML/XML like syntax.

With REST resources not having a concrete type meaningful to a client it gets rather hard to imagine how a client can instruct a server on which properties of a resource to return. In GraphQL a client therefore has to have some upfront knowledge about the resource at hands and its type, something I have talked about here.

One way to combine REST and GraphQL though was answered by Fielding like this:

A client can POST to a REST service to create a resource that is a GraphQL query, and then GET that resource with all benefits of REST… (Source)

However, as you've asked for alternatives. REST operates on a simple premise, a server should teach a client everything it can do and has to know to make a further request. On the Web, with widespread HTML support, a server provides a client a set of links it can request further content for or returns a HTML representation that contains a <form>...</form> section. This is basially the way how a Web server teaches a client on where to send the request to (target URL), what HTTP operation to use, which media-type to use on marshalling the request (often implicitly given as application/x-www-url-form-encoded) and of course the properties a resource supports. This is HATEOAS. We use the hypertext to drive the client through a workflow, or as Jim Webber called it through the domain application protocol, that behaves like a text based couputer game or a Web shop checkout by providing options to a client it can follow.

So, how do Web forms help in approximating GraphQL? Well, a server can simply provide the options in a form which parts to return. Think of a checkbox that includes each field a resource has that can be checked and if checked will be present in the response. Depending on the amount of properties a resource has, certain groupings can be suggested by the server as well. This eliminates the necessity for external documentation or upfront knowledge and depending on how the client processes the response is also a future proof way to teach a client on the options a client has.

Besides HTML forms, you also have some JSON based ones like hal-forms or ion that you can use.

Answer 2

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.