2

I am writing an article about traditional REST vs GraphQL.

However, after doing some research about REST (not just a specific implementation of REST), I started to see that GraphQL actually abides to the same rules as REST, with 1 minor exception.

IMPORTANT: I am talking about the actual REST specification. I am not just talking about a traditional implementation of REST.

REST principles are described here:

These are:

  • Client Server Architecture
  • Statelessness
  • Cacheability
  • Layered system
  • Uniform interface
    • Resource identification in requests
    • Resource manipulation through representations
    • Self-descriptive messages
    • Hypermedia as the engine of application state (HATEOAS)

GraphQL trivially satisfies the criteria of "Client Server Architecture", "Statelessness" and "Layered System".

A GraphQL implementation can be made to satisfy cacheability, by enforcing that id is required for every resource (see: https://graphql.org/learn/caching/)

Which leaves "Uniform Interface", which has 4 sub-constraints:

Resource identification in requests

Individual resources are identified in requests.

GraphQL satisfies Resource identification in requests, as there is no mention that the resources must be in the URL or the usage of HTTP verbs.

Therefore both:

GET /books?fields=title

and

POST /graphQL
{
    books {
        id
        title
    }
}

are REST compliant.

Resource manipulation through representations

When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource.

GraphQL can satisfy this, provided the resource identifier attribute is included for every request. i.e. the following would be invalid:

{
    books {
        title
        author: {
            name
        }
    }
}

but the following is valid:

{
    books {
        id
        title
        author: {
            id
            name
        }
    }
}  

Although I would argue that a good API should not return data that we don't need. The client should choose if they want the ID or not, but I digress.

Self-descriptive messages

Each message includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a media type.

GraphQL satisfies this as the data returned is JSON, and the media type is application/json.

Hypermedia as the engine of application state (HATEOAS)

Having accessed an initial URI for the REST application—analogous to a human Web user accessing the home page of a website—a REST client should then be able to use server-provided links dynamically to discover all the available actions and resources it needs. As access proceeds, the server responds with text that includes hyperlinks to other actions that are currently available. There is no need for the client to be hard-coded with information regarding the structure or dynamics of the application.

GraphQL doesn't satisfy HATEOAS perfectly, but nor do many other real API's that claim to be RESTful.

This criteria is also pointless when using GraphQL, because everything is done on a single URI.

However, it is worth noting that GraphQL also has a feature called Introspection, which allows the client to get information about what queries the server supports and the documentation, which in a way is more helpful than just a URI.

Conclusion

So to conclude, it seems that GraphQL satisfies:

  • Client Server Architecture
  • Statelessness
  • Layered system
  • Resource identification in requests
  • Self-descriptive messages

By enforcing that id is required for every resource, it can also be made to support:

  • Cacheability
  • Resource manipulation through representations

And doesn't really need to support:

  • Hypermedia as the engine of application state (HATEOAS), because everything is done on one URL, and GraphQL has introspection.

Therefore can we conclude that GraphQL satisfies REST, with the exception of HATEOAS (which IMO is the worst part of REST anyway).

Am I correct, or have I misunderstood the REST spec.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2

5
  • 1
    You should probably review: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven Dec 10, 2018 at 12:59
  • I am writing an article about traditional REST vs GraphQL it could be interesting to see how you put in the same level two totally different things. GraphQL has nothing to do with REST in any meaningful way.
    – Laiv
    Dec 10, 2018 at 13:22
  • 1
    @Laiv I think overlapping use cases are a valid and meaningful axis on which to compare two solutions. REST and GraphQL are both widely used for web APIs, so there definitely is merit in writing out their pros and cons compared to each other. Aside from that it's really not relevant to the question, which is clear and answerable regardless of usefulness.
    – kevin
    Dec 10, 2018 at 14:12
  • I'm confused by your description of the Fielding dissertation as a specification. While it contains an objective definition of what REST is and isn't, I'm don't think it's a 'specification'. Your description of it as 'a set of principles' is more apt.
    – JimmyJames
    Dec 10, 2018 at 16:39
  • HATEOAS is actually the best part of REST. The problem with HATEOAS that most people misunderstood is that the benefit of HATEOAS isn't clear until you've made the effort to satisfy all the other constraints first. Most APIs tried to cut corners by skipping some constraints the they think they don't really need, and then failed to realise the benefits of HATEOAS. Introspection isn't HATEOAS, and provides none of the benefits that HATEOAS does.
    – Lie Ryan
    Jun 28, 2021 at 17:11

1 Answer 1

5

No, GraphQL is not RESTful in any meaningful way.

Yes, when viewed in isolation it certainly is possible to develop a RESTful architecture that makes use of GraphQL. And in principle, GraphQL is already cacheable even when not introducing any IDs.

But as normally used, GraphQL is not RESTful.

  • In particular, GraphQL-over-HTTP certainly does not use HTTP in a RESTful way whereas “normal” RESTful APIs are nothing more than HTTP used in a specific style.

  • One interesting difference is that a GraphQL query may touch multiple resources/objects in one query. This doesn't make caching impossible, just very hard. For example, you cannot leverage HTTP caching but have to roll your own.

  • GraphQL doesn't even have a clear concept of a resource. Instead, you have an object graph. It is not always possible to tell where one object ends and another starts, unless we use simplistic definitions that are based on JSON objects or GraphQL's type system. Instead we might say: in GraphQL, the graph is the only resource.

  • GraphQL subscriptions break with the typical 1:1 query:response pattern. It could be argued that this clashes with REST's statelessness principle since the subscriber will be notified when the server's state changes. In particular, the presence of a subscription is shared state.

In summary, I'd say that GraphQL is about as RESTful as any other Web-based API: probably not RESTful by default, but can be used in that style if explicitly designed that way (possibly avoiding certain features).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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