REST is an architectural style, or design pattern, for APIs.
The Representational State Transfer (REST) architectural style is an API worldview that elevates information from systems into a first-class element of architectures. REST allows to achieve the architectural properties of performance, scalability, generality, simplicity, modifiability, and extensibility.
Who invented REST?
REST was defined by Roy Fielding, a computer scientist. He presented the REST principles in his PhD dissertation in 2000. The ideas and terms described as “RESTful” systems were introduced and collated in Dr. Roy Fielding’s thesis, “Architectural Styles and the Design of Network- based Software Architectures”.
REST stands for REpresentational State Transfer.
It means when a RESTful API is called, the server will transfer to the client a representation of the state of the requested resource.
For example, when a developer calls Instagram API to fetch a specific user (the resource), the API will return the state of that user, including their name, the number of posts that user posted on Instagram so far, how many followers they have, and more.
Before we dive into what makes a RESTful API and what other constraints and rules you should follow if you want to create RESTful APIs, let me explain few key terms:
1. Client — the client is the client software (web, mobile, system, bot etc.) who uses the API. You can be a developer to use twitter API to read and write data from social media feeds, create new tweets, newsfeeds and do more actions in a software program. The software program will call twitter’s API. The client can call this program via web browser, mobile or thru any interface and uses the returned data to render information on the screen.
2. Resource — a resource can be an object that API can provide information about. In Instagram’s API, for example, a resource can be a user, a photo, or a hashtag. Each resource has a unique identifier. The identifier can be a name or a number.
3. An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer creates the API on the server and allows the client to talk to it.
4. REST determines how the API looks like. It stands for “Representational State Transfer”. It is a set of rules that developers follow when they create their API. One of these rules states that you should be able to get a piece of data (called a resource) when you link to a specific URL. Each URL is called a request while the data sent back to you is called a response.
5. The representation of the state can be in a JSON format, and probably for most APIs this is indeed the case. It can also be in XML or HTML format. What the server does when you, the client, call one of its APIs depends on 2 things that you need to provide to the server:
1. An identifier for the resource you are interested in. This is the URL for the resource, also known as the endpoint. In fact, URL stands for Uniform Resource Locator.
2. The operation you want the server to perform on that resource, in the form of an HTTP method, or verb. The common HTTP methods are GET, POST, PUT, and DELETE.
A RESTful API exposes information about itself in the form of information about its resources. It also enables the client to take actions on those resources, such as create new resources (i.e. create a new user) or change existing resources (i.e. edit a post).
The design rationale behind the Web architecture can be described by an architectural style consisting of the set of constraints applied to elements within the architecture. By examining the impact of each constraint as it is added to the evolving style, we can identify the properties induced by the Web’s constraints.