REST API

REST API is an API that complies with the design principles of REST(REpresentational State Transfer) architectural style. It is also known as Restful API, first presented in the year 2000 by computer scientist Dr. Roy Fielding in his doctoral dissertation.

This architecture style mainly depends on HTTP(HyperText Transfer Protocol), which loads webpages using hypertext links. REST output data in XML, YAML, and many formats but JSON is the most popularly used format.

The contents of the REST architecture such as all format pages such as text, HTML files images, and videos are referred to as resources. A client can modify and access all resources on the server. The resources act as an object or database entity and it is identified by URI (Uniform Resource Indicator). The server transmits the value of the object in the specific format that matches the client’s standard format and is hence referred to as REpresentational State Transfer.

Need For REST API

If you are developing apps such as a weather app, news, time, and date app, or tools for email verification, plagiarism check, etc, you need huge data about temperature and local news of the different locations.

It is impossible to collect all data and store it on our own server which is expensive instead, we can use available web services.

Web Services:

Web services are web applications that use standards and protocols to interact and exchange data with clients. It means the interaction between two machines or systems over a network.

A set of rules that explain how an application or service inside the same device can interact and communicate with each other is known as an API (Application Programming Interface).

The application or service that makes the request and access the resources is known as a client.

An application that sends a response to the request sent by the client is known as the server.

Principles Of REST API

The six principles of REST API are

• Stateless
• Client-Server
• Uniform Interface
• Cacheable
• Layered System
• Code On Demand

Stateless:

The client’s request should contain all the information the server needs. Information such as the URL for uniquely identifying the resource and the body which has the state of the requesting resource. The server needs this information since it does not retain any previous session information and hence improves performance.

Client-Server:

The client-server design enforces a separation that helps the client and server to act independently.

This improves the user interface portability across multiple platforms and improves the scalability of the server components.

Uniform Interface:

The uniform interface simplifies the architecture and enables each part to act independently

Some of the four constraints specified by REST to obtain a uniform interface are

1. Identification of resources: Uniform Resource Identifiers(URI) identifies individual resources in the RESTful Webservices. The data returned by the server to the client need not necessarily be the same as the original internal representation.
2. Manipulation of resources through representation: The representation of the resource such as metadata in the client is sufficient to modify or delete the state of the resources in the server.
3. Self-descriptive messages: Resource representation must include information that describes how to process the message and additional action the client can perform on resources.
4. Hypermedia as the engine of the application state: With just the initial URI of the application, the client must access dynamically all the needed resources using the hyperlinks provided by the server.

Cacheability:

Responses must define themselves as cacheable or non-cacheable. It implies whether the client has the right to reuse the response for a specific period. If it is cacheable prevents unnecessary client-server interaction.

Layered System:

The layered system architecture stabilizes the application by limiting the component behavior. It enables load balancers to provide shared caches and improve scalability and call multiple servers to send responses to a client. Also enhances application security by limiting the interaction with layers other than immediate layers.

Code on-demand(optional):

In REST, the servers extend the functionality of the client temporarily by transferring executable codes such as applets and javascript.

Methods of REST API:

The REST API enables us to develop web applications and perform CRUD(Create, Read, Update and Delete) operations using the HTTP method.

Standard HTTP methods are

• GET
• PUT
• POST
• DELETE

HTTP GET:

GET methods are used to retrieve resource representation and it should be idempotent, which means making multiple requests does not change the state of the resource.

GET API Response Codes:

If the requested resource is found then the server returns response code 200(OK).

The server returns code 404(Not found) if a requested resource is not found.

If the request is not correctly formed, then the server returns the response code 400(Bad Request)

Now let us take a look at the example of implementing the GET method by using the free REST API such as JSON placeholder which provides sample data for testing and learning purposes.

Example 1:

HTTP POST:

The POST method is used to create a new resource such as creating a row in a database table. It is non-cacheable unless mentioned and not idempotent, which means making multiple requests will result in different resources with the same information.

POST API Response Codes:

If the resource is created, the response code is 201(Created) and includes an entity that describes the status of the request, newly created resource, and Location header.

The response will be 200(OK) or 204(No content) returned if no resource is identified by the URI using the POST method,

Example 2:

HTTP PUT:

The PUT method is used to update the existing resource and creates a new one if not found. The PUT method is not cacheable.

PUT API Response Codes:

If the resources are updated successfully then response code 200 (Ok) or 204 (No Content) is returned.

Response code 201(Created) is returned if a new resource is created by the POST API.

Example 3:

HTTP DELETE:

The DELETE method is used to delete the resource and is referred to as idempotent and the responses are not cacheable.

DELETE API Response Code:

If the resource is deleted successfully and includes an entity to describe status then response code 200 (Ok) and if no entity 204(No Content) is returned.

The response code or status will be 202 (Accepted) if the action is queued,

If the DELETE method is called for a second time, the status will be 404(Not Found).

Example 4: