Representational State Transfer (REST)

From Coder Merlin
Revision as of 11:14, 20 August 2021 by Akshat-sharma (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Within these castle walls be forged Mavens of Computer Science ...
— Merlin, The Coder

Restful api cat.jpg

What is REST?[edit]

REST, or representational state transfer, defines a set of rules that acts as the architecture for interactions with REST web services. It uses HTTP to request and access data from such services that are broken down to smaller modules that have their own functions.

What is an API?[edit]

An API, Application Programming Interface, is a software interface that facilitates communication between various programs. This allows parties to send requests and receive responses to each other with the intent of transferring data effortlessly. The main usage of APIs is for companies to open up their application to other people, such as third party developers or business partners, and give them access to its functionality and data to aid in collaboration projects or produce new business relationships.

REST Architecture[edit]

  • Client-server architecture: REST’s flexibility comes from the separation of the interface from the data storage, allowing different components to evolve independent of each other.
  • Statelessness: no client context is stored on the server between requests
  • Cacheability: instead client data is stored in the cache which is faster. REST API response must explicitly state whether it can be cached or not.
  • Layered system: the API will work whether it is communicating directly with a server, or through an intermediary such as a load balancer.
REST Implementation

REST Process[edit]

Content is broken down into smaller chunks of data that are responsible for its own part of the transaction. The content is retrieved through commands:

  • GET to retrieve a resource
  • PUT to change the state of or update a resource, which can be an object, file or block
  • POST to create that resource
  • DELETE to remove it

REST API Principles[edit]

Client-Server Architecture[edit]

  • REST APIs follow a Client-Server model; clients request and receive various data to and from a centralized server. This ensures that the client cannot directly interact with the centralized server and the centralized server cannot directly modify the client application. The separation allows for different components to learn from each other. Client-server utilizes HTTP to request and receive data to and from the server.

Statelessness[edit]

  • The stateless protocol requires client requests to the main server to contain all information necessary to fulfill the request. This includes the previous packets and context information from previous requests and sessions will not interfere with the current and relevant web session. This is advantageous as it allows RESTful interfaces to scale as applications grow in volume; the statelessness increases performance by removing the need of retaining previous session information.

Layered Systems[edit]

  • The layered architecture employs hierarchical layers that are unable to see beyond the layer that they are interacting with. This increases stability so that layers are unable to accidentally change data from another layer.

Uniform Interface[edit]

A uniform interface allows for a simplified and separate architecture. REST API systems are uniform; information transferred between the server and client is in a standard form. In order for REST APIs to be uniform, they must follow four rules.

Resource Identification

  • A request for data is identifiable and separate from the representation of data that is received from the client.

Resource Manipulation

  • When data or a representation of a resource is received from the Client, it needs to have enough information to tell the Client the correct way to process that data or resource

Self-Descriptive Messages

  • Messages that are sent to the Client will also come with instructions and information on how to process the said message.

Hypertext/hypermedia

  • Hypertext/Hypermedia needs to be available for the client after resources or data is accessed or sent to the client. After the client successfully gains access to sent resources, the client is able to use hyperlinks to find out of other actions or resources that are available. A hyperlink is a reference to data a user or clients can follow, and hypermedia is a way for a URL to change what branch in the webpage directory it is in.

Code on demand[edit]

  • Optionally, the REST API allows servers to provide clients with code to execute certain processes when requested, which augments client functionality by allowing code to be executed client-side.

Cacheability[edit]

  • Caching allows for users to retrieve data faster, by getting data from a local memory storage (cache) rather than having to access the database for each request for data. According to REST API guidelines, performing a GET command to retrieve data should not change the server in any way. Cacheability essentially allows for temporary storing of information that is provided to the client, which means certain data requests can be reused without having to communicate with or access the server again.

Why use REST?[edit]

One of the biggest advantages of using a REST API comes from the flexibility it provides. As a set of guidelines, REST is able to be used with various data formats, structures, languages, and ultimately allows for developers to frame their program to meet their needs. Additionally, REST APIs can be scaled to fit any size of application or program. A lot of APIs begin to struggle when an application begins to require more resources, but REST is able to handle the increasing size and complexity with ease.

Real World Applications[edit]

Many large companies such as Twitter, Instagram, and Spotify use REST APIs to allow access to their data. In fact, this API structure is so versatile that many developers believe it is on track to becoming the industry standard for APIs in web development.

Picture of Roy Fielding at OSCON08

History[edit]

The REST architectural style was created by Roy Fielding in 1999 where he added it to his 2000 PhD dissertation called “Architectural Styles and the Design of Network-based Software Architectures” at U.C. Irvine. Fielding analyzed the requirements that a world-wide network-based application required for global adoption through surveying existing architectural styles, identifying which features are shared among different styles.

Key Concepts[edit]

Key ConceptsKeyConceptsIcon.png
  • API
    • Application Programming Interface
  • REST
    • Client-server architecture: REST’s flexibility comes from the separation of the interface from the data storage, allowing different components to evolve independent of each other.
    • Statelessness: no client context is stored on the server between requests
    • Cacheability: instead client data is stored in the cache which is faster. REST API response must explicitly state whether it can be cached or not.
    • Layered system: the API will work whether it is communicating directly with a server, or through an intermediary such as a load balancer.
    • Uniform Interface: REST API are uniform, standardized and follow four rules.
      • Resource Identification
      • Resource Manipulation
      • Self-Describing Messages
      • Hyperlink/Hypermedia
    • Code on Demand: Allows the client to handle and execute code provided from the server

References[edit]