REST stands for “Representational State Transfer”. This is an architectural style. A web API conforming to this style is a REST API.
REST stands on 6 guiding principles, important among them are:
- Client-server: separate backend and frontend.
- Stateless: each http request contains enough data (e.g. auth, session, user data) to understand it without knowing what the previous request was.
- Cacheable
- GET: always
- POST: using http headers
expire,cache-control,etag,last-modified - PUT, DELETE: never
Concepts
The following are some important, concise, and simplified REST concepts a good backend dev must be familiarized with.
Resource
REST APIs are modeled as a resource hierarchy – where each node is either a collection, or a single resource. A single resource has some state, or sub-resources.
Example of a stateful resource is the following, where a user resource has data/states:
POST /users/:id
{
id: 4e7d418a70f,
name: 'muhammad',
country: 'earth',
verified: true
}
Example of a resource with sub-resources is the following, where a user has multiple projects, each of which are a resource.
GET /users/:id/projects
content-type: application/json
[
{
id: 'postman cli',
desc: 'postman implemented in command-line'
url: 'github.com/midnqp/postman-cli'
},
{
id: 'typescript',
desc: 'typescript is a superset of javascript',
url: 'github.com/microsoft/typescript'
}
]
Idempotency
API Idempotency means “a client can make a request multiple times, returning same response – without having any side-effect”.
Making the following requests multiple times produces the same result, and has no further side-effect – thus are “idempotent” APIs:
-
GET /users/:id– just retrieving same user data -
PUT /users– just updating same json data -
DELETE /users/:id– just deleteing the same user
A non-idempotent API:
-
POST /users/:id– because a new user will be created everytime this request is made
