REST, or the representational state transfer, is a way to simply create, read, edit or delete information from the server using simple http calls.

REST is an architecture of the interface designed for a distributed environment. REST was designed and described by Roy Fleding in 2000. Unlike known XML-RPC or SOAP, REST is data-oriented, not procedurally oriented. All sources has their own URI identifier and REST subsequently defines four basic methods that can access them.

Rest’s concept

Rest is a concept of the distributed architecture design which is considered as an architecture in which part of the program runs on different machines. A network is used for their communication. You can imagine a web application, for example, under such program. There, the internet browser communicates with web server.

Rest’s basic principles

  • The behavior and condition of the application are expressed using the so-called resource (key abstraction). Each resource must have assigned a unique indentifier, i.e. URL or URN.
  • Hypermedia as the Engine of Application State, also known as HATEOAS. This means, that the state of the application is determined using the URL. Further states can then be obtained directly from the links client receives in the reply sent by the server.
  • REST defines united access for obtaining resources and manipulating with them. The manipulating includes four operations, so-called CRUD (Create, Read, Update, Delete).
  • Resource can be represented in various ways, for example using XML, HTML, JSON, SVG or PDF. The client then doesn’t work directly with this resource but only with its representation.

Communication protocol

The communication is divided into client and server which allows the separation of responsibilities. The protocol is stateless and therefore it is necessary that each requirement contains all the information necessary for its implementation.

The requirement can be marked as cacheable or non-cacheable. This makes it possible to increase performance transparently. The protocol allows the Code-On-Demand function which extends the client functionality with the code sent by server. REST makes it possible to fold layers that provide services. This increases variability for example for cache, transformation or load distribution.

The advantages of using REST API

  • Scalability. This protocol’s scalability is outstanding. Thanks to the division into client and server part, the product can be scalated by the development team without any major problems.
  • Flexibility and portability. It is possible to migrate from one server to another, or to change databases at any time. It is essential to just send the request correctly. Frontend and backend can be on separate servers, a big advantage in terms of management.
  • Independence. The division into client and server part allows simpler and independent development across different parts of the project. Moreover, REST API is always adapted to work syntax and platform. This allows you to test different environments.

The advantages of REST over SOAP

  • Easier to build and adopt.
  • Minor resource claims.
  • Explicit formation of processes instances.
  • With the initial URI, it is no longer necessary for the client to request routing information.
  • The client may have a general listener interface for collecting notifications.

When to use REST API

  • When client and server operate on the web environment.
  • When there is no need to send information about objects to the client.

When not to use REST API

  • When it is necessary to require a strict contact between the client and the server
  • When it is necessary to start transactions requiring multiple calls.

Examples of common use

  • Media network services.
  • Social networks.
  • Web chatting services.
  • Mobile services.

Favourite examples

  • Twitter API
  • LinkedIn API
  • Slack API