REST has a bad rap. This architectural pattern is often explained like a long incantation in Latin. The name itself is also not user friendly, being an acronym for “Representational State Transfer”. More often then not, the explanations sound like utterances in an alien tongue. This post hopes to express the principles ideas of REST in plain old English. While many definitions explain REST in detailed and verbose manners: I prefer simplicity. And stories. So to paraphrase Deckard Cain, stay awhile and listen.

What Webapps Think About

While some of the other things I’ve posted about let’s us think from a servers perspective (Strapi). Today let’s think what a modern day web app thinks. Its inner monologue would be something like “Is this user signed in? Who are they? What data does this user or non-user have access to? Are there other services I’ll need to call to with this users credentials? What should I do if I need more data for this user?” The main point of these questions is that a web app needs to know who’s using it in many cases, and this determines the state (what data is loaded up). The data, it’s all about the data.

The Tale of Sessions

A long time ago, a user’s data was stored on the server. This was called the “session” variable. Whenever a user returned or asked for things from the server, the server would look at the session and approve accordingly and all was well. But then came many users. Followed by many many users. The server scaled and scaled in size and price to accommodate a growing number of requests, but things got out of hand. There had to be a better way.

(Rest in plain English means) the state is determined by the credentials the user sends the server.

And there was! How can we represent the state of a user without storing them temporarily in the memory of a server? One way is when a user signs in we’ll give them an encrypted token with various permissions and some small data maybe about them. The user (i.e. browser) can save that data in it’s cookies or local storage and that’ll act as their identification when they make requests. Then whenever they try to change something or access something that requires authorized data, we’ll check that the token they have is correct, and act accordingly. Suddenly the servers didn’t have to care about who was coming in or leaving, just scanning their requests for proper identification and doing data actions accordingly. And this is REST in a nutshell, the state is determined by the credentials the user sends the server.