The History of REST APIs: The Architecture That Powered the Modern Web

You’re reading this article on a website. That’s obvious. But how did this page get from a server somewhere to your screen? The answer, more often than not, is a REST API. REST—Representational State Transfer—isn’t just a buzzword. It’s the architectural style that quietly reshaped the internet from a collection of static pages into the dynamic, app-driven ecosystem we now take for granted.

Let’s trace how we got here.

Before REST: The Wild West of Web Services

In the late 1990s, building a web API meant picking SOAP (Simple Object Access Protocol). SOAP was verbose, rigid, and XML-heavy. To call a function like getUser(id), you’d craft a massive envelope of XML, send it via HTTP POST (always POST), and parse a complex response. It worked, but it felt like mailing a letter just to open a door.

Developers hated it. The dream was simpler: use HTTP as it was designed—GET to fetch, POST to create, PUT to update, DELETE to remove—and return data in a lightweight format. Enter Roy Fielding.

Roy Fielding’s Doctoral Thesis That Changed the Web

In 2000, computer scientist Roy Fielding published his PhD dissertation at UC Irvine. Chapter 5 described something he called “Representational State Transfer.” It wasn’t a library or a framework. It was a set of constraints, an architectural style. Fielding had been one of the key authors of the HTTP specification, and he wanted to codify why the web worked so well for humans—and how to make it work the same way for machines.

The core idea? Resources. Every piece of data—a user, a photo, a blog post—is a resource identified by a URL. You interact with it using standard HTTP methods. The server never remembers who you are between requests (stateless). And you can use any format you like: JSON, XML, or even plain text.

Fielding wasn’t trying to invent something new. He was trying to explain why the web had scaled so beautifully. But in doing so, he gave developers a blueprint.

The JSON Revolution (And Why It Won)

REST might have stayed an academic curiosity if not for JSON. JSON (JavaScript Object Notation) was much lighter than XML, and it natively looked like a JavaScript object. When browsers started running more JavaScript, JSON became the obvious choice for APIs.

By the mid-2000s, major companies started exposing RESTful APIs. Flickr released a REST API in 2004. Amazon Web Services offered REST endpoints for S3 in 2006. Twitter’s API was famously RESTful. Developers could now build apps that fetched data from remote servers with a single fetch() call.

Suddenly, you didn’t need a SOAP library. You didn’t need to marshal XML. You could do it with curl and a text editor.

REST Meets the Mobile Era

When the iPhone launched in 2007, the world changed again. Mobile apps needed to talk to servers, and battery life and data limits meant every kilobyte mattered. SOAP was dead weight. REST with JSON was lean, cacheable, and stateless—perfect for a phone that might lose signal at any moment.

This is where REST truly became the default. Every mobile app you’ve ever used probably communicates with a REST API behind the scenes. Instagram? REST. Uber? REST. Your bank’s mobile app? Almost certainly REST.

The “Pragmatic REST” Problem

Here’s where things get messy. Fielding’s original constraints are strict. True REST requires hypermedia controls (HATEOAS—Hypermedia As The Engine Of Application State). That means the API response should tell the client what to do next, like a website with links.

In practice, almost nobody does that. Most “REST APIs” are really “HTTP JSON APIs” that follow some conventions. You use GET for reads, POST for creates, and maybe PUT or PATCH for updates. You return JSON. You don’t include navigational links.

Fielding himself has called this out. He’s said that if you’re not using hypermedia, it’s not REST. But the industry didn’t care. The spirit of REST—simple, resource-oriented, stateless—was already winning.

GraphQL, gRPC, and the Future

REST isn’t the only game anymore. Facebook released GraphQL in 2015, giving clients more control over exactly what data they fetch. gRPC, built by Google, offers high-performance binary communication, popular in microservices.

But REST isn’t going away. It’s still the default for public APIs. It’s the simplest to understand, the most widely supported, and the most cacheable. GraphQL is great for complicated UIs, but REST remains the workhorse.

The story of REST is a reminder that the best ideas often come from observing what already works. Roy Fielding didn’t invent the web—he explained it. And that explanation gave us the architecture behind almost every modern application you use.

So next time an API call loads your dashboard, your feed, or your comments, you’re living in the world Fielding described. It’s not perfect. But it worked well enough to build the internet we rely on every day.