API or Application Programming Interface presents functions and rules that allow interaction and communication between different applications. These interfaces facilitate application integration, enabling developers to create powerful digital products.
The API mediates between applications via requests and responses. For instance, registration in the application through the user's existing Twitter account occurs through the Twitter API that developers have integrated into the app.
The API uses various protocols and architectures for sending requests and responses:
- XML-RPC — allows the exchange of functions between networks. XML-RPC uses XML to describe responses/requests and HTTP protocols for information transferring from client to server.
- JSON-RPC is a lightweight RPC similar to XML. Here protocol is encoded in JSON; it allows receiving calls to the server with asynchronous responses.
- SOAP — a simple object access protocol for exchanging structured information when implementing web services in computer networks. SOAP uses XML for authentication, authorization, and process communication on operating systems. It allows clients to call web services and receive responses regardless of platform and language.
- REST API (representative state transfer) — an architectural style using client-server implementations independently. REST uses HTTP protocol for communication.
In this post, we focus on the REST API, define it, and analyze how it differs from other APIs.
Defining REST API
REST is an architectural style for designing APIs through the HTTP protocol. Its key benefit is its great flexibility.
Developers use REST API wherever there is a need to provide data to the user of a web application or site directly from the server.
The main components of the REST API:
- Client — a client or program launched on the user's side (on his device) initiating communication.
- Server — a server using APIs as access to its functions and data.
- Resource — any content (video, text, picture) the server transmits to the client.
How the REST API works
REST API communicates through HTTP requests, completing the following functions — creating, reading, updating, and deleting data. They are also known as CRUD operations. REST provides the information about requested resources and uses four methods to describe what to do with a resource:
- POST — creating a resource;
- GET — getting a resource;
- PUT — updating a resource;
- DELETE — deleting a resource.
A resource is a critical concept in REST API, an information abstraction. It could be any information: document, image, temporary service.
Resource's state at any given moment is known as resource representation which consists of data, metadata describing the data, and hypermedia links to help customers move to the next state.
The information can be delivered to the client in various formats: JSON, HTML, XLT, Python, or plain text. The most popular and used one is JSON because it is human and machine-readable, and language-agnostic.
To access a resource, a client needs to make a request. After receiving it, the server will generate a response with encoded data about a resource.
The request structure includes four main components: the HTTP method (CRUD we mentioned earlier), endpoints, headers, and body.
The HTTP method describes what should be done with the resource. Just above, we mentioned four available methods: POST, GET, PUT, DELETE.
The endpoint contains a URI — Uniform Resource Identifier, which indicates how and where the resource can be found. A URL or Uniform Resource Location is the most common URI type, representing a full web address.
Headers contain the data related to the client and the server. Headers include authentication data: API key, name, IP address that belong to the computer on which the server is installed, and also the information about the response format.
The body is used to send additional information to the server, such as data that you want to add.
REST API principles
REST is not tied to any particular technology or platform. It is language-independent. It also doesn't specify precisely how to build the API. But it uses six architectural constraints. The interface can be called a valid REST API by following those constraints. They describe how the server processes requests and responds to them.
The REST API implements a client-server architecture style. The client is sending requests for resources and is not associated with the data storage. Data storage remains inside the server. Servers are not involved in the communication with the user interface. The client and server evolve interdependently. This factor makes the REST even more flexible and scalable.
The unified interface is an essential factor distinguishing the REST API. It states that there is a single way for communicating with the server, not implying the type of application and device.
The uniform interface has four principles:
- Identification of resources. Each resource must have an identification that is independent of the resources state. The URL acts as an identifier.
- Manipulation of resources through representations. A resource representation (that client has) contains the data required to delete or modify the resource. The client sends a representation that the server (a JSON object) needs to modify, remove, or add.
- Self-descriptive messages. Such messages have all information for the recipient for its understanding. No additional information is required in separate documentation or messages. Each message has enough information for the server to parse the request.
- Hypermedia as the engine of application state. Hypermedia requires links usage for each response so that the client can find other resources. In REST, hypermedia is used for all interactions.
It means that the server doesn't contain any data about the client. All information needed for request processing is included in the request. The client stores all session information.
Each response must have the information telling if it is cacheable or not and the period the response can be cached. If it is cacheable, then in similar requests, the client can use the same data without repeatedly sending requests to the server. It helps improve performance and availability.
REST implements the layers hierarchy, which creates certain restrictions on the behavior of components. In a layered system, components can only see the components located at the nearest levels and those they interact with.
Code on demand
It is an optional feature allowing clients to download and execute code.
What differentiates REST API?
The REST API's six principles can be considered the key differences between this interface and other types. In addition, several parameters distinguish REST.
First, the very essence of REST determines its incompatibility with other types. It is an architectural style where an architecture represents a set of requirements you need to follow to provide a RESTful web service. For example, SOAP and RPC are messaging protocols that describe messages. Unlike the architectural style, which only specifies the requirements (constraints) the message must fulfill.
Usually, API follows the app-to-app format, while REST follows a different structure — Client-Server. The client and server are evolving independently, providing more flexibility in work.
Message exchange format
APIs usually use specific message formats; for example, SOAP uses XML. REST does not follow such a strict principle. It can use almost any format to exchange data. However, JSON is now the most popular one.
REST is a flexible architectural style, so developers widely use it. Compared with SOAP — a more complex protocol with advanced security features requiring more bandwidth, REST consists of simple guidelines that allow developers to use those requirements in their format. The architecture provides high performance, making it especially in demand for mobile devices, where download speed is important.
As we see, REST has certain advantages over other known APIs. That is why all leading companies such as Twitter and Google have implemented it for their products. After all, it's the ideal and easy way to transfer data to developers around the globe and a proven mechanism for creating efficient and scalable interfaces for software development.