Introducing the Cato Cloud API: Why We Chose GraphQL over REST
Enterprise and managed service provider (MSP) customers have been asking Cato for an API that would let them use their existing third-party provisioning, ticketing and management systems to run and retrieve data from their Cato deployments. Today, we fulfilled that request with the Cato Cloud API.
In doing so, we made the decision to implement the new API in GraphQL rather than the legacy REST architecture. For those of you more accustomed to REST, I’d like to take this opportunity to explain in detail why we chose GraphQL, and how this approach brings several significant advantages over REST.
Why an API?
As with any API, Cato’s is meant to give third-party management, SIEM, orchestration, and other software programmatic and data access to the Cato cloud. With the Cato Cloud API, large enterprises and MSP’s can automate the provisioning and monitoring of their Cato deployments — either individually or as part of a larger infrastructure deployment — using their existing non-Cato tools and platforms.
The Cato Cloud API is identical to the one used by Cato’s own management application, so customers have access to all the same event data that Cato can access. The Cato Cloud API is unique from legacy APIs in that it provides:
- Access to security and networking data through a single programmatic interface, gaining organizations efficiencies in monitoring and controlling Cato deployments.
- Pre-normalized data, with all security and networking event data in the same format and structure. This saves development time that would otherwise be spent normalizing data for analysis.
- Granular data retrieval via GraphQL that tailors requests to retrieve only the necessary data.
- A single API for the entire network across all sites and global users via a single aggregation point, rather than separate API’s for each individual device.
REST: Simple but Rigid
Why did Cato choose GraphQL instead of REST? To understand the reasoning, let’s take a closer look at the advantages and disadvantages of each.
REST has long been a popular API architecture and industry standard for system-to-system integration. REST endpoints are plentiful and well developed and there are lots of developers with REST expertise who know how to work with its well-defined API calls and consistent output. REST is also relatively simple to understand and use.
The other side of that simplicity, however, is that REST can often be rigid and inefficient.
REST has two potential inefficiencies. The first—often called under-fetching–is that it requires separate calls, at times for each individual attribute but, more commonly, for multiple objects. As such, you might have to string together a large number of calls to get all the data and control you need. For example, retrieving the upstream and downstream bandwidth available at a site may require two separate calls, and definitely will require separate calls when retrieving those attributes across multiple locations .
The second — often called over-fetching — is that each REST call can only return a single predefined set of data fields, which means you may end up retrieving a lot more data than you actually need for the purpose at hand, requiring further extraction. For example, REST may return a username, ID, birth date, and any other number of other user fields, when you’re simply trying to extract a user ID.
This rigidity puts a burden on the API creator to understand the user’s precise data requirements. If they don’t, or the requirements change, the creator may have to go back to the drawing board and spend time changing the REST API calls. All too often, REST APIs remain frozen in time, locked to particular versions due to the high cost and the long turnaround time needed for even minor API changes.
The bottom line: REST is simple and familiar, but rigid and potentially inefficient.
GraphQL: Flexible and Efficient
GraphQL is a query language, specification, and set of tools operating over a single endpoint using HTTP. Its advantage is its flexibility and precision. With a single GraphQL query, software can retrieve all the data fields and only the data fields you need. This flexibility makes Graph QL much more efficient to use and takes pressure off the API creator, who no longer needs to know exact user requirements. Adding new fields to the API can happen in days not months. It also makes it infinitely more suited to the frequent iterations and design improvements common to today’s development environment.
The minor downside is a little more complexity than REST and perhaps a smaller pool of individuals–today–with GraphQL experience and expertise. Thus, with GraphQL, the burden is shifted from the API creator to the API user, who is likely to encounter a bit of a learning curve on the way to mastering GraphQL query syntax and options.
This shouldn’t scare you, however. When we’ve shown GraphQL to engineers they’ve perceived it simply as a more adult version of REST, something closer to writing a MySQL query, with which many are already familiar. Cato provides the training and documentation to get organizations up to speed with the GraphQL API architecture fast. In return, users get a powerful combination of the Cato cloud and an API that can query the entire cloud instance for the exact data required with a single call.
Putting the API Discussion to Rest
To understand the full power of the Cato cloud paired with the Cato Cloud API, let’s look at managing a Cato deployment of 100 sites with a third-party management tool.
With a typical REST API solution, you would likely have to query a few hardware devices at each of the 100 sites, with several REST calls per device, thanks to REST’s under-fetching issues. Let’s assume you would need 10 calls for each site. That means you would likely have to create a total of 1,000 REST calls over all 100 sites. In the process you might end up with massive amounts of data you don’t need and every time anything changes either in the Cato environment or the management platform, many of those REST calls would likely have to be rewritten or adjusted.
Now consider the same scenario using the Cato cloud and the Cato Cloud API with GraphQL. Thanks to the API’s ability to query security and networking data across the entire deployment and thanks to GraphQL’s ability to retrieve only the data you need, the grand total number of API calls required would likely add up to—drumroll—one. One vs. a thousand: As you can see, the efficiency and time savings are almost too good to pass up. And each time there’s a change to the Cato platform or your management tool, it’s likely you won’t have to do anything.
Customers look to Cato for an agile, forward-looking, future proof network and security solution. The Cato Cloud API, built on GraphQL, fits perfectly with that mission.
MSPs and channel partners interested in taking advantage of the API and joining the Cato ecosystem should visit https://www.catonetworks.com/partners/