REST Architecture
According to the official definition, REST is an acronym for REpresentational State Transfer and an architectural style for distributed hypermedia systems. Roy T. Fielding first presented it in 2000 in his famous dissertation "Architectural Styles and the Design of Network-based Software Architectures". Since then it has become one of the most widely used approaches for building web-based APIs (Application Programming Interfaces)
REST is not a protocol or a standard, it is an architectural style. During the development phase, API developers can implement REST in a variety of ways.
Let's chew this up a little.
What is REpresentational State Transfer? REST is just the action of transfering the current state of a resource. A resource can be an image, a JSON object, a text.. anything that comes from a server is a resource. Therefore, when we send a request, we get (hopefully) a representation of something that exist on the server.
For example, imagine we have a class in C#. This class contains properties and methods. When we send a request to the server, the server creates an object from that class, call some of it's methods, populates the properties, and creates a response, call it a representation of the class and send (transfer) that representation back. If the response comes in form of a JSON object, for example, only the data will be received, so what we receive its a "version" (aka representation) of the state of that class after it completed it's function.
REST is about creating representation of object's current state and transferring that representation over the network.
Now, there are principles that define a RESTful architecture. In order to be able to say that a system is RESTful they have to met the following characteristics.
Uniform interface
A uniform interface is a set of rules used to define how clients and servers interact. REST is a Client-Server architecture, therefore a "contract" must be defined to specify how the client and the server talk to each other.For example, let's assume that you have a Client that sends the name of a person to the server to get stored somewhere. The uniform interface to perform that operation uses the URL of the server, the url paramters defining the type of action that the client wants to perform, and the structured message that the client wants to send.
An example of the URI for that operation would be something like this:
https://myserver.com/api/name/add
The client will use a POST method to send the request to the server, and in the body of the request the client will send a JSON object like this one:
{ name:"Merak" }
Both Client and Server have agreed on a "uniform interface" to perform this operation. The URI, the parameters, the HTTP method and the structure of the message.
Client Server
Like mentioned before, REST rely on a Client Server design pattern. This helps separating the roles of each actor, where the Client is responsible for getting and initiating the operations, the server is responsible for performing the actions requested (computing, storing data, etc). Since they are separated, we can change each one without affecting the other, give that we maintain the way they talk to each other (the uniform interface)
Stateless
Each interaction between a Client and a Server has to be atomic. The Server cannot (and must not) remember his conversation with a Client. Each request sent by a Client has to be a complete question, and its the responsibility of that Client to remember the Server answer. Why? We cannt ask the server to have an open ended conversation with a Client for the simple reason that maybe at some point a single server will be talking to millions of Clients, and it will not have enough resources to remember all.
Cacheable
Imagine a Client that ask the Server what day is today. The server can easily say "Friday" every time, but it wont be better to say "It's Friday, and it will be Friday for the next 6 hours and 17 minutes"?. Marking a Server response as cacheable allows the Client to skip asking again before the answer expires. However, that does not mean that the Client cannot ask again...and again...and again...