# REST is an API architecture built on six constraints.

# 1. Uniform Interface

Defines the interface between clients and servers. Decouples the application and enables each part to work and evolve independently. There are 4 primary principles within the concept of uniform interface:

# Resource based

Resources are identified by URIs (/lists/1234/items/1)

Resources can be conceptually separate from representations sent to client

A server may need to touch several storage locations or services to get all the data that represents what a ListItem is, but from the perspective of the client ListItem is a singular resource

# Manipulate resources via representations

A client that has a representation of a particular resource should have everything it needs to modify that resource on the server

# Self-descriptive messages

Each message should include enough information to process it.

# HATEOS (Hypermedia as the Engine of Application State)

Clients deliver state to the server (request body, headers, querystring, etc)

Servers deliver state to the client (response body, headers, HTTP status codes, etc)

As needed, server can provide links to related resources. Related resources can be used to describe relationships, used in pagination, etc

# 2. Stateless

All of the state required to process a request should be contained in the request itself. This state can be transferred as part of the URI, request body or headers, or querystring.

This implies that state tracked by the server, e.g. traditional “sessions”, are in violation of RESTful principles because at least some information required to process the request is not included in the request itself

Statelessness allows for much better scalability, as the server does not have to maintain or communicate state. It also makes load balancing simpler and more performant because load balancers do not need to worry about which server a client should be directed to.

# 3. Cache-able

Responses should explicitly or implicitly define themselves as cacheable. This allows clients to avoid some trips to the server and further improves scalability and performance.

# 4. Client-Server

Clients are not concerned with data storage, making client code more portable.

Servers are not concerned with views or user state, making them more scalable and simpler

Servers and clients can be updated and replaced independently, as long as they expose the same interface

# 5. Layered System

Clients should not be able to tell if they are connected directly to the server or to an intermediary server.

Intermediary servers can handle things like shared response caches, load balancing, and the enforcement of security policies, leading to further improved performance and scalability.

# 6. Code on Demand (optional)

Servers can extend client functionality by sending executable code to the client. These could be JavaScript libraries, Java applets, etc.