REST APIs vs GraphQL: Both Have Their Strengths for a Headless CMS
While the advantages and disadvantages of both REST APIs and GraphQL have been hotly debated in recent years, the reality is that both approaches have their uses. The standardization that GraphQL provides also brings limitations that only REST APIs can surpass. That’s why many software vendors are offering support for both.
It’s nearly impossible for CMS vendors to predict how companies will use their APIs, especially with omnichannel content delivery becoming the norm. It’s crucial, therefore, for the CMS to give developers the option to use whichever technology is best suited for the task.
With this in mind, let’s look at why developers may prefer GraphQL and why REST will still be around for a long time into the future.
GraphQL Brings Many Improvements Over REST
The main advantage GraphQL brings over REST is decoupling the retrieval of data from where it’s located on the backend. Developers can describe the data they want in a request, therefore, and receive it in the response without knowledge of particular databases or data structures. This innovative approach is because GraphQL servers follow a standardized querying language. Here are some of the reasons why this approach is most useful.
CRUD functionality is easier to maintain
Most developers turn to GraphQL for basic CRUD — create, read, update, delete — operations.
The reason for this is that GraphQL brings limitations when it comes to advanced data manipulations — such as composite transactions — because of its standardized querying language. GraphQL, however, brings enormous benefits for READ or data retrieval requests specifically because the technology standardized for the most common data requests a developer would want to make.
Furthermore, the GraphQL server is introspective, so backend developers can simply update the schema and frontend developers can easily edit their API requests to match it. That means it’s straightforward to maintain as the backend infrastructure changes. REST APIs, on the other hand, are often time-consuming for developers to maintain and document.
Further Reading: Is GraphQL the Next API Standard for CMS?
It’s simple to match requests with frontend requirements
The primary situations that favor GraphQL are integrations with frontend frameworks and user interfaces. You can often make a single GraphQL request that retrieves the specific data for a frontend component, for example, while a REST API may require multiple requests and risks over-fetching of data. The ability to tailor API requests also streamlines the integration with less flexible legacy applications.
That’s not to mention the time saved in learning the standard GraphQL querying language that’s introspective instead of proprietary REST APIs with varying qualities of documentation. Learning GraphQL’s standard querying language can save developers time when they’re integrating multiple systems with the frontend that they’re building. That means more time to improve the customer experience and user interface rather than learning proprietary REST APIs.
Why GraphQL Won’t Fully Replace REST
While the lack of standardization for REST APIs is often seen as a significant disadvantage, it’s also what enables their flexibility. There are many situations where REST APIs are used well beyond simple CRUD operations because they can support highly sophisticated transactions better than GraphQL. Here are the main reasons to favor REST APIs over GraphQL for some use cases.
Caching is much less complex
Caching is often less complicated with REST APIs because requests are tied to specific resource URLs or endpoints. With GraphQL, even if the same resources are contained in a request, the specific fields could be slightly unique. And GraphQL only uses one endpoint to handle requests. Caching, therefore, must be done on the field level instead of the broader resources or HTTP level.
Unlike GraphQL, REST APIs can cache frequently accessed data along the way from local caching to proxy and reverse proxy caching. Oftentimes, these caching techniques that REST APIs utilize can outweigh the performance drawbacks of over-fetching and under-fetching data. Caching, therefore, can drastically reduce the burden on servers and computing resources.
Complicated integrations are more straightforward
REST APIs are most useful for complex system integrations because they can handle more advanced queries beyond CRUD. With REST APIs, for example, it’s possible to use more sophisticated data types such as unions, product types, and other data structures. Developers can also make batch requests to REST APIs.
GraphQL, on the other hand, has limitations that make it less than ideal for complex systems integrations. This is especially true for legacy systems written in outdated languages because there is far less library support for GraphQL. In addition, performance can suffer when using GraphQL for complex integrations if the client requests too many fields from multiple data structures in one request. This puts pressure on the server in terms of processing the requests with resolvers and wasting bandwidth on bloated responses.
There’s No One-Size-Fits-All Technology
When it comes to APIs, there is no single approach that’s ideal for every situation. And just like REST hasn’t fully replaced SOAP services, GraphQL likely won’t fully replace REST APIs in the near future either. That’s why Crafter CMS supports both REST and GraphQL out of the box.
If you'd like to integrate with frontend frameworks, Crafter’s native GraphQL support with automatic schema generation may be your best option. If you have a complex system integration, however, Crafter’s REST APIs may be better suited to the task. Or any combination of each approach as developers see fit. Crafter believes the best developer experience is the one that uses the right tool for the job and provides developers with the most flexibility.
Crafter is always on the lookout for the latest technologies that facilitate digital innovation. That means offering as many points of integration and approaches as possible so that organizations can bring the best tools available into their tech stack. A robust set of REST APIs along with GraphQL support gives developers a variety of options for integrating with both frontend and backend systems. These technologies each have their place in the developer toolset, so Crafter will continue to improve upon them well into the future.
Russ Danner is VP Products at Crafter Software and is responsible for product management, product development and support, and client and partner success. Russ brings over 20 years of software architecture, design, and implementation experience. Prior to Crafter Software, Russ was Web Experience Management Practice Director at Rivet Logic and project lead for the open source Crafter CMS project.