Of late, GraphQL has been presented as a revolutionary alternative to REST APIs—but as with anything else, it has its pros and cons. In some scenarios, GraphQL will indeed be a better solution, but in others, you might find that REST APIs are still preferable. This blog post will walk through the basic differences between GraphQL and REST APIs so you can make the best possible decisions for your automation needs.
GraphQL: An Introduction
GraphQL follows the same set of constraints as REST APIs, but it organizes data into a graph using one interface. Objects are represented by nodes (defined using the GraphQL schema), and the relationship between nodes is represented by edges in the graph. Each object is then backed by a resolver that accesses the server’s data.
When a GraphQL server responds to an end user’s request, it begins with the query root, and the resolver executes every field on the requested object. A key-value map houses each field’s values, and some return another object selecting another set of fields. This continues until only a string or a number is returned. The server then responds with a nested set of objects, as requested by the end user.
The Core Difference Between REST APIs and GraphQL
A REST API is an architectural concept for network-based software. GraphQL, on the other hand, is a query language, a specification, and a set of tools that operates over a single endpoint using HTTP. In addition, over the last few years, REST has been used to make new APIs, while the focus of GraphQL has been to optimize for performance and flexibility.
Where GraphQL Has the Upper Hand Over REST APIs
When using a REST API to fetch information, you’ll always get back a complete dataset. For example, if you wanted to request information from two objects, you’d need to perform two REST API requests. The advantage of REST APIs is its simplicity—you have one endpoint that does one task, so it’s easy to understand and manipulate. In other words, if you have X endpoint, it provides X data.
Conversely, if you wanted to gather some information from a specific endpoint, you couldn’t limit the fields that the REST API returns; you’ll always get a complete data set. This phenomenon is referred to as over fetching. GraphQL uses its query language to tailor the request to exactly what you need, from multiple objects down to specific fields within each entity. GraphQL would take X endpoint, and it can do a lot with that information, but you have to tell it what you want first.
In essence, GraphQL is extremely powerful, once you know how to use it. Because you are only fetching the data that you require, you limit the amount of processing required. As you begin to look at automation, these savings really start to add up.
Where REST APIs Beat Out GraphQL
REST has become the industry standard for companies deploying APIs. REST endpoints are mature and have been around for a while. Even “late-to-scene” OEMs have REST endpoints now, and if you have done any type of automation, you’re going to be familiar with REST.
Similarly, API analytics are easier to obtain for REST, due to the limited amount of tooling for GraphQL. There is a promise of more insights in the near future, once tools that support GraphQL are made more widely available.
The Bottom Line on GraphQL
With GraphQL, there is a learning curve, which isn’t nearly as established as REST APIs, but that learning curve is worth it. When creating automation, your life can become so much easier if you receive only the data you need and nothing else. As an added bonus, the performance of your automation increases because you’re not having to process a large amount of data. At scale, any performance improvements you can include are big wins.
To get started with Rubrik’s own APIs, join Rubrik Build, our open source community. There, you’ll find tons of SDKs, tooling integrations, and use cases. Rubrik Build is designed for users of all skill levels–so dive right in!