You don't know the difference between HTTP and REST

You've heard about RESTful API. But have you ever stopped to look up what it means? What does the term include? What exactly is part of REST and what should you take into consideration when building your web services?

In this blog post we're going to take a trip to the early days of web and try to answer these questions to get an understanding of the term. Much of this chapter references the paper Architectural Styles and the Design of Network-based Software Architectures by Roy Fielding, which I urge, despite it's technical complexity, you to read with a thought if you're working in the web industry.

The early rise of the World Wide Web

The year is 1994. You're one of the fortunate researchers with the access to a growing network of inter-connected computers called the Web. The advantage of the Web is, that you can use your organization's computer to browse the growing number of documents shared by other users of the Web.

The idea behind the Web is revolutionary – instead of having a closed mainframe that would contain all the data, it is possible for anyone to share their own information to the Web by popping up a new server that holds the files.

This has started to spread outside the research groups: The Web now includes everything from clubs to individual peoples' personal home pages. It is becoming clear that the Web is going to grow out of it's boundaries.

The state of the Web before REST

The early implementation of Web was rather simple: You'd need a computer to host the information you'd want to share, fire up a server software (that's based on the libwww client-server library) to serve your static documents, connect the computer to the Web and you're done. Now anyone can request your documents on demand, even outside your campus, even from another country.

But the Web was growing. Requesting a popular piece of document from another physical location was suboptimal: Even if the document was already once downloaded to a nearby physical location, there was no other way but to always fetch the content from it's source. You could cache the document to your own computer, but the growing number of interactions would yield in growing demand of connecting hardware within the physical locations of Web.

And the people were using the new technology in very new ways. Instead of simple hypertext documents, people were also including images in their websites (which were inlined to the document, as the initial version of HTTP only could serve a single document per connection and new connections were costly).

The birth of REST

Given the new, rapidly growing demand and use case for the Web, many working groups got formed to develop the web further. One of these groups was the HTTP Working Group, which worked on the new requirements to support the future of the growing World Wide Web.

One member of the HTTP Working Group was Roy Thomas Fielding, who simultaneously worked on a broader architectural concept called Representational State Transfer — REST.

So REST architecture and HTTP 1.1 protocol are independent from each other, but the HTTP 1.1 protocol was built to be the ideal protocol to follow the principles and constraints of REST.

One way to look at the relationship between HTTP and REST is, that REST is the design, and HTTP 1.1 is an implementation of that design. In reality the two were designed simultaneously.

REST to the rescue

So how did the working groups solve the problem of the growing Web?

The HTTP 1.1 could be summed up like this:

The client requests documents from the Server
The server is stateless, all state is handled by the client
Client might cache the requests for future use

Especially the concept of allowing clients to cache the downloaded assets was a crucial step for the scalability of the Web. Let's take an example:

Consider that your indie band just recorded the hit song of the summer 1997 and suddenly everyone's downloading the same file from your poor FTP server. There are intermediate hardware between you and the downloaders that could easily help you to handle the load, only if they knew they could cache the file on your permission.

Fortunately you know exactly what to do: You download the latest version of the Apache Web server and create a simple Web page with Hypertext Markup Language (HTML) that points to the song with a hypertext link.

Next you set the Apache Web server to send the song file with a HTTP 1.1 Cache-Control header with the cache directive public as it's value. Now you have allowed any intermediate caches to serve your song without asking your server – reducing the amount of network transfer needed to serve the song to all your fans around the world.

One of the principles of REST is, that the server response should always state whether the response can be cached or not. HTTP 1.1 implements this with e.g. the Cache-Control header.

Takeaways

It's easy to take old technologies like REST and HTTP as granted, since they pretty much make up the whole Internet as we know it today. Yet the technologies have a clear concept of why they exist in a first place, since they have played an important role in the early days of the Web.