What is REST API?
REST API has emerged as the most versatile and useful web service API. Its simplicity, flexibility, and compatibility make it ideal for working with various types of data and interfacing with the most well-known applications available. In this article, we’ll define REST (or RESTful) API and take a look at how it compares to its predecessor, SOAP. In addition, we’ll explore how REST APIs work and why the trend towards cloud integration makes REST APIs so essential for businesses today.
What is REST API?
REST (Representational State Transfer) or RESTful API is a type of API, or Application Program Interface, that helps web service applications communicate with each other. While it is theoretically compatible with any protocol or data format, REST most often uses the HTTP protocol and transfers data using JSON (JavaScript Object Notation). REST is one of the most popular choices for getting data from the web due to its flexibility, speed, and simplicity.
Until 2000, SOAP (Simple Object Access Protocol), developed by Microsoft, was the most widely used platform for client-server interactions. While SOAP was both useful and popular, the protocol had two disadvantages. First, it required users to adhere to strict rules regarding how to interact with the server. Second, it relied on the cumbersome XML format.
Dissatisfied with the SOAP methodology, computer scientist Roy Fielding proposed an alternative called “REST” in his 2000 doctoral dissertation. The key characteristics that set REST apart from its predecessor were increased formatting flexibility, increased speed, and reduced bandwidth. Today, REST is one of the most common types of API and is used by most major web providers including Amazon, Facebook, Twitter, and Google.
REST API Design
Like all APIs, REST helps move data between users and applications. For example, whenever you log into a website or access an app on your phone, an API helps your client communicate with the host server. APIs are the go-between that deliver your requests to the server and return the server’s response to you.
Client Request
The process begins when a client in the REST architecture uses HTTP commands to send requests to the server. For example, when you open a web page by typing an URL, you’re actually sending an HTTP request such as ‘GET + URL’. Similarly, a REST client uses these kinds of commands to access the information you’ve requested. The most common HTTP commands include:
- GET – Retrieve a specified resource
- POST – Create a new resource
- PUT – Update an existing resource
- DELETE – Delete an existing resource
For example, the HTTP command “GET https://api.bookseller.com/customers/” retrieves the names of all customers from the bookseller’s website.
Server Response
Once a client request is initiated, the REST API retrieves and delivers a response. These include a range of resources including data, images, videos, web addresses, comments, blog posts, tweets, etc. When the client requests a resource from the server, the server does not send back the resource itself, but responds with a representation of the resource.
These responses are most often delivered in the JSON format. This format is both human and machine readable, and it’s compatibility with most programming languages makes it an ideal choice for the flexibility of REST API.
6 REST API Constraints
A major advantage of REST APIs are their simple syntax requirements. But they do operate by a set of design rules, called “constraints.” For an API to be considered RESTful, it has to adhere to the following six constraints:
Uniform Interface
A uniform interface means that every REST client can call the server and access its resources in the same manner, whether that client is a browser, JavaScript code, or a mobile application. This is made possible by using an URI (Unique Resource Identifier), which is often a URL such as “https://api.twitter.com/”
Requests and responses must be self-sufficient – the client sends all the information that the server requires to process the request and the server returns a response with information to modify, delete, or simply access the resource requested.
The server must have the ability to include hyperlinks which allow the client to modify the resource. This feature is known as ‘hypermedia as the engine of application state’ (HATEOAS).
Client-Server Architecture
In the REST architecture, the client and server components are clearly defined and separated. This modular design allows both components to be changed independently with no impact to the other. Most web clients and servers are designed this way; REST simply makes this constraint explicit.
Statelessness
In a RESTful design, the client-server interactions are stateless. This means that the server does not have to remember the client state either by storing it in memory or databases. Hence, all the information required by a server to return data has to be included in a given request.
Statelessness puts the responsibility of maintaining application state purely on the client. The server is rendered light-weight as it does not have to store any overhead data about client calls to serve future requests.
Scalability is easier in a stateless architecture. However, clients may have to make multiple calls to a server to get data which may bring down performance. Usually, web developers find ways to optimize client application performance by reducing the number of hops to the server.
Layered System
A layered system refers to the complete decoupling of client and server. When a client application makes a request using an endpoint URL, it does not have to be aware of the exact server catering to its request. There may be multiple layers of servers, each performing its own unique set of functions such as load balancing, caching, etc., but the client remains oblivious to all this behind-the-scenes action.
Layering adds additional security to REST API, since attacks or events can be isolated and contained within individual layers. In addition, the entirety of the architecture is never exposed.
Cacheable
REST servers can cache data. Using the Cache-Control header, the server informs its client whether the data sent is being cached (or not) and the duration for which the particular response is valid. Once the initial duration has expired, the client pings the server again for an update. Version numbers are also used for the client to determine if it has the latest state of the resource requested.
Code-on-demand
This is the only constraint that is optional in a RESTful design. Code-on-demand is a feature where the server sends a code snippet, which the client then executes on its end. For example, the code is sent as JavaScript within a HTML response.
Differences Between SOAP and RESTful APIs
The debate between REST and SOAP has been ongoing for the better part of two decades. Each interface has its uses, and each comes with its own strengths and weaknesses. Although many enterprises continue to rely on SOAP, REST has emerged as the most popular API due to its adaptability and lightweight architecture. In order to understand what distinguishes REST from SOAP, it’s helpful to compare the two:
SOAP is a protocol while REST is a design style. SOAP requires much stricter standards of communication and syntax, while REST only lays down high-level architectural guidelines (six constraints), allowing for more flexibility in implementation.
REST has faster performance as it consumes less bandwidth and resources. SOAP works only with XML data format, which results in larger file sizes. REST which can work with less bulky formats such as HTML, JSON, and even plain text.
SOAP requires tighter binding between client and server. When the SOAP server function is invoked, the SOAP client needs to know the exact signature of these functions. If the signature changes, the interface breaks.
Since a REST client only calls out resource names, it does not need to be aware of the API implementation details. If the server changes its implementation, the client does not have to make any modifications at all. This allows REST to achieve a greater degree of client-server separation than SOAP.
REST calls can be cached. The cacheable property of REST APIs means that data can be reused by the web browser rather than making multiple calls to the server. This is a more sophisticated design option that helps to conserve bandwidth.
SOAP is generally considered to be more secure. SOAP supports WS-Security and SSL standards. It also has in-built ACID (Atomicity, Consistency, Isolation, Durability) compliance that makes it more suitable for highly secure enterprise applications and systems that deal with sensitive data such as payment gateways and telecom services. However, REST does support SSL and HTTPS standards.
REST API and Cloud Integration
The major trend in data management today is the move toward cloud integration. APIs allow users to access information stored in the cloud, across multiple servers, and in various formats. Although REST APIs are most commonly used with SaaS (software as a solution) platforms, they also play an important role for PaaS (platform as a service) providers. Some of the most well-known providers who use RESTful APIs include Oracle, Jira, Google, Adobe, Amazon, and GitHub.
With so much at stake when it comes to cloud computing, companies are increasingly looking for ways to make sure that their products and services are prepared to deliver the full functionality of the cloud. In most cases, this means using a cloud integration tool that provides REST API connectors and capabilities.
Cloud API Services from Talend simplify the process of creating APIs to help you get the most from your data. With a complete set of tools to ensure data quality and over 900 connectors, you’ll be have your APIs up and running faster than ever before. Start a free trial today to see how easy your integration can be.
