In my last blog post, I made the presumably controversial claim that Representational State Transfer (REST) wasn’t about building APIs. Rather, REST is an architectural style for building distributed hypermedia applications. So, what’s special about those?
Hypermedia is simply an update to the notion of hypertext: text files with hyperlinks to other text files, only now we’ve expanded the concept to include other types of data like audio and video files. And what does REST have in do with building such hypermedia applications? According to Roy Fielding, who is the primary author of the REST architectural style, REST is defined as being a style for building hypermedia applications. So how do we build hypermedia applications? In his papers, Fielding described hypermedia applications as applications that allow the user to click on links to navigate from one state to another; the actual data is held at various network nodes (such as web servers). The data includes “links” that allow the user to navigate from one
document to another. What’s key, from an architectural perspective, is that users navigate from hyperlink to hyperlink, which means that the application logic—the sequence of available transitions from one state to the next—is not embedded within the client itself. Instead, it comes from the server to the client as a result of user interaction.
That’s a very important distinction—instead of the client owning the application logic, the server is responsible for sending the next state of the application to the client. That is a fundamentally different way of thinking about application design, and it has a pretty fundamental implication on how we should be building web services and APIs.
From the server’s perspective, the client is just a hypermedia engine that executes a script sent down from the server. The server sends down an HTML page that has embedded links to tell the client what transitions the user is allowed to make, and when the user clicks on a link, the browser submits a request to the server that identifies that link. The server then responds with a page that shows the results of that link’s associated action and includes new links for the user to click on. This process of following links is, in essence, an automated way of navigating an application state machine. The key thing that I want to emphasize is that the server is in control of the state machine—that’s what defines the application logic. The client doesn’t know (and doesn’t need to know) what the valid transitions are from one state to the next; the server tells the client what transitions are allowed by sending down links that the user can click on.
Charlie has over a decade of experience in website administration and technology management. As the site admin, he oversees all technical aspects of running a high-traffic online platform, ensuring optimal performance, security, and user experience.
