What is REST (and is it old news)?

REST is an acronym for Representative State Transfer. It refers to an API architecture style, or set of constraints developers follow when creating APIs. RESTful web services can be consumed by HTTP requests to fetch and manipulate data.

It was the original alternative to SOAP (Single Object Access Protocol), which had been too complex to build, use and debug. Before REST, web APIs were flexible but not very accessible. That is, until 2000, when Roy Fielding created an API standard which would eventually become REST. With REST, servers around the world would be able to communicate with each other.

REST uses a uniform interface, and it is client-server based. Requests made using REST are stateless, and it makes caching easier given that single resources can be identified better through a URL structure in a RESTful web service.

These are some of the rules which REST follows, and at the time, these rules seemed excessive. However, they successfully made APIs simpler, reducing the learning curve for new developers and organizing the world of APIs. At the time, REST was also more flexible, mobile-friendly and required less bandwidth, plus it was adaptable.

However, one of the drawbacks of REST is that fetching data from REST structured web services can lead to an increased number of HTTP requests, or too much data returned. With standard REST, you access a single resource/entity, and it’s impossible to define which attributes of entities you want to retrieve.

This can lead to over-fetching, where you get too much data or under-fetching when you don’t get all required data with your request, contrasting with the declarative data fetching of GraphQL.

Several organizations are favoring GraphQL for many reasons, but that doesn’t mean that REST doesn’t have its own advantages.