REST API

In this article, I’ll try to explain the REST API. I will explain what is meant by REST API, why use REST API, the method of HTTP, and the principle of REST API. We have been using various software and web pages to get data for different applications since the invention of the internet. Nonetheless, have you ever thought about where this data comes from? Well, it’s the servers that we get the data. So in this article explained REST API, let us look into how a client communicates with the servers to extract the required information.

What is REST API?

REST is short for representational state transfer. I know it probably doesn’t make any sense to you. because it was introduced by a PhD student as part of his thesis. REST API is designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design.

In a client-server communication, REST suggests creating an object of the data requested by the client and send the values of the object in response to the user. For example, if the user is requesting details of one of the countries in the world, then you can create an object on the server-side. So, now you have an object of the data the user is requesting, and you are sending the state of the object. Thus, REST transfers the state of an object of data requested by the client from the web or application server. This is why REST is known as Representational State Transfer.

REST API Basics

Why use REST APIs?

Many of the most popular web and cloud companies use REST APIs for their applications, including Facebook, YouTube, Twitter, and Google. But why REST? Basically, it’s an excellent system for web apps. Here are the main benefits to this type of API:

• REST APIs are flexible. They can handle many types of requests and send data in many different formats.
• REST APIs incorporate existing web technologies, making them relatively easy to build and use. To request a resource via a REST API, you just need to provide its URL.
• REST APIs are scalable. They are designed for communication between any two pieces of software, regardless of size or capability. As a web application grows and adds more resources, its REST API will be able to quickly handle the increasing amount and variety of requests.

HTTP Methods

REST APIs enable you to develop any kind of web application having all possible CRUD (create, retrieve, update, delete) operations. REST guidelines suggest using a specific HTTP method on a particular type of call made to the server

HTTP GET

Use GET requests to retrieve resource representation/information only and not to modify it in any way. As GET requests do not change the state of the resource, these are said to be safe methods.

HTTP POST

Use POST APIs to create new subordinate resources. Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. Please note that POST is neither safe nor idempotent, and invoking two identical POST requests will result in two different resources containing the same information (except resource ids).

HTTP PUT

Use PUT APIs primarily to update existing resource (if the resource does not exist, then API may decide to create a new resource or not). The difference between the POST and PUT APIs can be observed in request URIs. POST requests are made on resource collections, whereas PUT requests are made on a single resource.

HTTP DELETE

As the name applies, DELETE APIs are used to delete resources (identified by the Request-URI). DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resources. Repeatedly calling DELETE API on that resource will not change the outcome. However, calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed.

HTTP PATCH

HTTP PATCH requests are to make partial update on a resource. If you see PUT requests also modify a resource entity, so to make more clear PATCH method is the correct choice for partially updating an existing resource, and PUT should only be used if you’re replacing a resource in its entirety.

As you read the above content, you may have come across two words. Those are a safe method and an Idempotent method. Idempotency and safety are properties of HTTP methods.

Safe Methods

As per HTTP specification, the GET method should be used only for retrieval of resource representations and they do not update/delete the resource on the server. Both methods are said to be considered “safe“.

Idempotent Methods

The term idempotent is used more comprehensively to describe an operation that will produce the same results if executed once or multiple times. So it does not matter if a request is sent once or multiple times. The following HTTP methods are idempotent: GET, PUT and DELETE. All safe HTTP methods are idempotent but PUT and DELETE are idempotent but not safe.

REST API Design Principles

Now you have idea about the REST API. Let’s move on to the six guiding principles of REST API design:

Client-Server

This principle works on the concept that the client and the server should be isolated from one another and permitted to develop independently. This way, you can improve manageability across numerous platforms and increase scalability by streamlining the server components as user-interface concerns are separate from the data storage concerns.

Stateless

As per this principle, REST APIs are stateless, which means calls can be made independent of one another. Moreover, every call includes the data essential to complete itself effectively. In other words, every request sent from the client to server must include all the info needed to comprehend the request. This can be either a part of URL, query-string parameters, body, or even headers. The URL is used to uniquely identify the resource and the body holds the state of the requesting resource. Once the server processes the request, a response is sent to the client through body, status or headers.

Cacheable

In order to provide a better performance, the applications are often made cacheable. This is done by labeling the response from the server as cacheable or non-cacheable either implicitly or explicitly. In case a response is cacheable, the client cache is provided the right to recycle that response data for similar requests in the future.

Uniform Interface

To achieve uniformity in interface throughout the application, diverse interface constraints are required to direct the component behaviours. REST has these interface constraints:

• Identification of the resources
• Manipulation of resources using representations
• Self-descriptive messages
• Hypermedia that works as an engine of the state of the application

Layered System

This allows the application to limit the component behavior making it more stable. Such architecture enhances the application’s security as the component’s interaction gets limited to the layer itself. This provides stability due to the shared caches. Also, it supports load balancing.

Code on Demand

This principle allows for coding or applets to be communicated through the API to be used within the application. A REST API definition permits extending client functionality by downloading and implementing coding in the form of applets or scripts. This streamlines clients by decreasing the number of features essential to be pre-implemented.

Most of the time, a server returns static resource representation in XML or JSON format. But when required, servers can deliver executable code to the client.

Conclusion

In this article, you learned the basics of REST API and I think now you have an idea about what is REST API, why we use REST API, methods of REST API, and principles of REST API. In the next article, I’ll hope to explain how to build a REST API with Node js & Express.