REST Facts for Kids

REST (which stands for Representational State Transfer) is like a special set of rules or a blueprint for how to design websites and apps that work over the Internet. It helps make sure that different parts of the internet, like your web browser and a website's server, can talk to each other easily and efficiently. REST focuses on making sure these systems are simple, can handle lots of users (scalable), and are easy to update.

When an application follows these REST rules, people often call it RESTful. This term is usually used for how web services (APIs) are built using HTTP, which is the main way web browsers communicate. It helps make sure that when you click a link or use an app, everything works smoothly and quickly.

What REST Means
How REST Started
What REST Helps With
REST Rules
- Uniform Interface Explained
Ways to Classify REST APIs
See also

What REST Means

The idea of representational state transfer was first explained in 2000 by a computer scientist named Roy Fielding. It means that when you ask a server for something (like a webpage), the server sends you a "representation" of that thing. This is usually an HTML document, which is what your browser shows you.

This document often contains hyperlinks. When you click these links, you are telling the system to change its "state" – for example, you move from one page to another. Each time you click, you get a new representation, and so on. This way, you only need to know the very first link to start exploring. All other links are discovered as you go. This makes the system very flexible, as the server can change its internal structure without you needing to know about it beforehand.

How REST Started

Roy Fielding speaking at a conference in 2008

The internet started becoming popular around 1993-1994, with more and more websites appearing. At that time, there wasn't a clear set of rules for how the internet's architecture should work. Many different ideas were being tried, and there was a need for a standard way for web systems to communicate.

Roy Fielding was part of the teams that created important internet standards like URI (which are like web addresses) and HTTP (the language browsers use to talk to servers). Over six years, he developed the REST architectural style. He used it to test and improve how the web worked. He officially defined REST in his 2000 PhD paper at UC Irvine.

To create REST, Fielding looked at what was needed for a worldwide network application, like making it easy for anyone to join and use. He also studied other ways of building network apps. He found features that were common, like caching (saving copies of data to make things faster) and client-server setups. He also found unique ideas for REST, like the concept of "resources" (anything on the web that can be identified, like a picture or a webpage).

Even though REST was created to help build the web, not every part of the web perfectly follows all of REST's rules. Sometimes, things don't quite match up because of mistakes or simply not knowing better. For example, Fielding pointed out that putting session information (like your login details) directly into web addresses (URIs) can make it harder for shared caching to work well. Also, HTTP cookies, which store small bits of information about you, can sometimes cause problems because they might not always match what your browser is doing.

What REST Helps With

REST is designed for applications that work over networks, especially those where a "client" (like your web browser) talks to a "server" (where the website's information is stored). It's built to work on a huge scale, like the entire internet. This means the client and server need to be as independent as possible.

This independence, along with sending information as simple text using standard web addresses, helps the internet meet its goals:

Extensibility: It can easily grow and add new features.
Scalability: It can handle a huge number of users and interactions.
Independent deployment: Different parts can be updated without breaking everything else.
Easy to use: It's simple for people to create and view content.

The rules of REST help improve several important things about how web systems work:

Performance: How fast things happen when your browser talks to a server.
Scalability: How well the system can handle more and more users or data.
Simplicity: Making the way different parts talk to each other easy to understand.
Modifiability: Being able to change or update parts of the system easily, even while it's running.
Visibility: Making it clear how different parts are communicating.
Portability: Being able to move parts of the system around easily.
Reliability: How well the system can keep working even if some parts fail.

REST Rules

The REST architectural style has six main rules. When these rules are followed, the system becomes better in many ways, like being faster, more scalable, simpler, and more reliable.

Here are the main REST rules:

Client/Server: The client (like your browser) and the server (where the website lives) are kept separate. They talk to each other through a clear, defined way.
Stateless: The server doesn't remember anything specific about a client between requests. Each request from the client must contain all the information the server needs to understand it. This makes servers simpler and able to handle more users.
Cacheable: Responses from the server should tell the client if they can be saved (cached) for later. This helps speed things up because the client doesn't always have to ask the server for the same information again.
Uniform Interface: This is a very important rule. It means there's a standard way for clients and servers to interact. This makes the system simpler and allows different parts to be updated independently.
Layered System: A client usually doesn't know if it's talking directly to the main server or to an intermediate server (like a proxy or a load balancer). This allows for more flexibility and security.
Code on Demand (Optional): Sometimes, a server can send small pieces of code to the client. This code can then run on the client's side to add new features or change how the client works temporarily.

Uniform Interface Explained

The uniform interface rule is key to REST. It makes the system simpler and allows different parts to change without affecting others. Here are its four parts:

Resource Identification: Every "resource" (like a specific webpage, image, or piece of data) has a unique address, called a URI. The resource itself is separate from how it's shown. For example, a server might send data as HTML, XML, or JSON, but these are just different ways to show the same underlying information.
Resource Manipulation through Representations: When a client gets a "representation" of a resource (like an HTML page), it should have enough information to change or delete that resource if needed.
Self-descriptive Messages: Each message sent between the client and server should contain all the information needed to understand it. For example, it might say what type of data it is (like an image or text) so the client knows how to handle it.
Hypermedia as the Engine of Application State (HATEOAS): This is a fancy way of saying that once you start at a main web address (like a website's home page), the server should provide links to all other available resources. You shouldn't need to know the entire structure of the website beforehand. You just follow the links provided by the server, just like you browse a website by clicking links.

Ways to Classify REST APIs

There are different models that help people understand how well a REST API follows the REST design rules. Some of these include:

The Richardson Maturity Model
The Classification of HTTP-based APIs

REST facts for kids

Contents