9

I saw in many sites that compare REST with GraphQL. after investigating this concern (actually my concern) that, "is it a correct comparison?", I being more confused. Since the REST has a different definition against GraphQL, this question busies my mind that, why we'll be able to compare two different concepts together.

actually, it seems to me that the comparison is something like this:

IDE Vs Compiler !??! or BMW x6 Vs ISO 18541-5 (Road vehicles)

from wiki:

Rest definition:

Representational State Transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.

GraphQl definition:

GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.

please brighten my mind with your answers. thanks

Improve this question
3
  • 1
    The GraphQL home page already describes the differences pretty well. What specifically do you need additional brightness about?
    – Robert Harvey
    Commented Jul 7, 2019 at 16:24
  • 1
    Both things can not be compared unless you choose to oversimplify what REST is and reduce it to mere web CRUDS through HTTP, what's definitively is not. It's like comparing SOA with SQL.
    – Laiv
    Commented Jul 9, 2019 at 8:42
  • Can you please add few examples of such articles / sites? It would help us to know the sources for this question :)
    – CorwinCZ
    Commented Jul 11, 2019 at 8:08

4 Answers 4

Reset to default
9

REST is an architectural style, developed in parallel with the world wide web in the 1990s.

The World Wide Web is a reference application for the REST architectural style (with some deviations).

HTTP is an application protocol for transferring documents over a network.

GraphQL is a query language and an execution engine.

You are right that directly comparing REST and GraphQL is a mess. What you can do, however, is look carefully at the kinds of problems they were trying to solve.

By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction. Fielding, 2000

In REST, caching is a big deal, and the current HTTP specification has an entire RFC dedicated to caching semantics; but folks using GraphQL have apparently decided that caching isn't significant for their problem.

As best I can tell, GraphQL is making a lot of the same coupling choices as SOAP. That's not right or wrong -- just a different balancing of the trade offs.

Improve this answer
5

No, this comparison is not valid.

As you have said, GraphQL and REST are different things, so it is like comparing apples and oranges.

That is one view / perspective of this problem. Second one is quite the opposite - GraphQL / REST comparisons are valid and very useful.

To understand this second view, we must ask this question:

What are the possible ways to deliver my data to clients? Which one should I pick?

Answer to the first question contains both REST and GraphQL (with many other ways). Both are useful for delivering data to clients (read - creating API's). The second question is actually the one which stands behind all the comparisons you have read.

Comparing different ways how to deliver data is valid and necessary. From this point of view it doesn't matter that nature of compared things is different. Both of them can do the job, so you should compare them.

It is like comparing taste of apples and oranges - you can do that.

Personally I'm doing this comparison all the time. Very useful for teaching fellow colleagues different ways how to solve problems.

Improve this answer
0

In my opinion as to this case: "REST is a protocol." Whereas, "GraphQL seeks to define content." GraphQL could be conveyed "across" more than one protocol.

Improve this answer
1
  • HTTP is a protocol, REST is a design pattern.
    – death and gravity
    Commented Sep 26, 2022 at 18:51
0

Its a comparisom of architectual approaches defined by their popular implementation, not the techincal implementations themselves.

If you take a "GraphQL" approach; you expose your database via a query interface, where the user can craft and send any query they choose to retrieve data. You dont have to actually use GraphQL.

If you take a "REST" approach; you write an API which exposes a set of specified operations to the user. You don't have to make that API RESTful.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.