What is REST (Representational State Transfer)?

REST (Representational State Transfer)

• REST is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other.
• RESTful systems are characterized by being stateless and separating the concerns of client and server.

Separation of Client and Server

• In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other.
• This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.
• Separating the user interface concerns from the data storage concerns improves the flexibility of the interface across platforms and improves scalability by simplifying the server components.

Statelessness

• Systems that follow the REST paradigm are stateless, meaning that the server does not need to know anything about what state the client is in and vice versa.
• This is achieved through the use of resources, rather than commands.
• Resources are the nouns of the Web, describing any object, document, or thing that you may need to store or send to other services.

Communication between Client and Server

• In the REST architecture, clients send requests to retrieve or modify resources, and servers send responses to these requests.
• A request generally consists of:
  • An HTTP verb (GET, POST, PUT, DELETE)
  • A header (e.g. Accept field)
  • A path to a resource
  • An optional message body containing data

HTTP Verbs

• GET: retrieve a specific resource (by id) or a collection of resources
• POST: create a new resource
• PUT: update a specific resource (by id)
• DELETE: remove a specific resource by id

Headers and Accept parameters

• In the header of the request, the client sends the type of content that it is able to receive from the server.
• This is called the Accept field, and it ensures that the server does not send data that cannot be understood or processed by the client.
• MIME Types are used to specify the content types in the Accept field, consisting of a type and a subtype (e.g. text/html, image/png, application/json).

Paths

• Requests must contain a path to a resource that the operation should be performed on.
• In RESTful APIs, paths should be designed to help the client know what is going on.
• Conventionally, the first part of the path should be the plural form of the resource (e.g. fashionboutique.com/customers).

Sending Responses

• Content Types:
  • In cases where the server is sending a data payload to the client, the server must include a content-type in the header of the response.
  • This content-type header field alerts the client to the type of data it is sending in the response body.
• Response Codes:
  • Responses from the server contain status codes to alert the client to information about the success of the operation.
  • Common status codes include:
    • 200 (OK): standard response for successful HTTP requests
    • 201 (CREATED): standard response for an HTTP request that resulted in an item being successfully created
    • 204 (NO CONTENT): standard response for successful HTTP requests, where nothing is being returned in the response body
    • 400 (BAD REQUEST): the request cannot be processed because of bad request syntax, excessive size, or another client error
    • 403 (FORBIDDEN): the client does not have permission to access this resource
    • 404 (NOT FOUND): the resource could not be found at this time. It is possible it was deleted, or does not exist yet
    • 500 (INTERNAL SERVER ERROR): the generic answer for an unexpected failure if there is no more specific information available