What is REST API? An Overview

What is REST?

The REST acronym is defined as a “REpresentational State Transfer” and is designed to take advantage of existing HTTP protocols when used for Web APIs. It is very flexible in that it is not tied to resources or methods and has the ability to handle different calls and data formats. Because REST API is not constrained to an XML format like SOAP, it can return multiple other formats depending on what is needed. If a service adheres to this style, it is considered a “RESTful” application. REST allows components to access and manage functions within another application.

REST was initially defined in a dissertation by Roy Fielding’s twenty years ago. He proposed these standards as an alternative to SOAP (The Simple Object Access Protocol is a simple standard for accessing objects and exchanging structured messages within a distributed computing environment). REST (or RESTful) defines the general rules used to regulate the interactions between web apps utilizing the HTTP protocol for CRUD (create, retrieve, update, delete) operations.

What is an API?

An API (or Application Programming Interface) provides a method of interaction between two systems. 

What is a RESTful API? 

A RESTful API (or application program interface) uses HTTP requests to GET, PUT, POST, and DELETE data following the REST standards. This allows two pieces of software to communicate with each other. In essence, REST API is a set of remote calls using standard methods to return data in a specific format. 

The systems that interact in this manner can be very different. Each app may use a unique programming language, operating system, database, etc. So, how do we create a system that can easily communicate and understand other apps?? This is where the Rest API is used as an interaction system.

When using a RESTful API, we should determine in advance what resources we want to expose to the outside world. Typically, the RESTful API service is implemented, keeping the following ideas in mind:

• Format: There should be no restrictions on the data exchange format
• Implementation: REST is based entirely on HTTP
• Service Definition: Because REST is very flexible, API can be modified to ensure the application understands the request/response format.
• The RESTful API focuses on resources and how efficiently you perform operations with it using HTTP.

The features of the REST API design style state:

• Each entity must have a unique identifier.
• Standard methods should be used to read and modify data.
• It should provide support for different types of resources.
• The interactions should be stateless.

For REST to fit this model, we must adhere to the following rules:

• Client-Server Architecture: The interface is separate from the server-side data repository. This affords flexibility and the development of components independently of each other.
• Detachment: The client connections are not stored on the server between requests.
• Cacheability: It must be explicitly stated whether the client can store responses.
• Multi-level: The API should work whether it interacts directly with a server or through an additional layer, like a load balancer.

HTTP Components

There are two main components here. The HTTP request structure and the HTTP response structure.

The HTTP request structure has the following attributes:

• Request Line – This defines the type of message.
• Header Fields – These fields define the message body, transmission parameters, and other information.
• Body – The request body, optional.

The HTTP response structure has the following attributes:

• Status Line – Provides a status code.
• Header Fields – Shows header response field.
• Body – An optional message body.

All interactions with a server come down to four basic operations:
(Four is the minimum, but in other implementations, there can be many more).

1. Receiving data from the server (usually in JSON or XML formats).
2. Adding new data to the server.
3. Modification of essential data on the server.
4. Delete data on the server.

There also exists, as noted above, the CRUD operation concept. CRUD is an acronym used for the four essential functions utilized when working with data: 

• Create
• Read
• Update
• Delete

The CRUD concept was introduced in 1983 by James Martin as the standard classifications of data manipulation. To perform these operations, various HTTP request methods are used.

• GET – get detailed information about the resource.
• POST – post creates a new resource.
• PUT – put updates an existing resource.
• DELETE – delete removes an existing resource.

HTTP Status Codes

Previously, when one of these requests was made using one of these methods, we could encounter errors and did not get a response at all. To solve this problem, HTTP status codes were devised.

1xx: Information

• 100: Continue

2xx: Success

• 200: OK
• 201: Created
• 202: Accepted
• 204: No Content

3xx: Redirect

• 301: Moved Permanently
• 307: Temporary Redirect

4xx: Client Error

• 400: Bad Request
• 401: Unauthorized
• 403: Forbidden
• 404: Not found

5xx Server Error

• 500: Internal Server Error
• 501: Not Implemented
• 502: Bad Gateway
• 503: Service Unavailable
• 504: Gateway Timeout

You may have already encountered some of these errors more than once, especially the quite popular 404 errors.

HTTP GET

Now, let’s look at an example using methods to create Rest API services.

We use HTTP GET to get (or read) a representation of a resource. If the address is successfully received (error-free), GET returns a JSON or XML representation in combination with the HTTP status code 200 (OK). In case of an error, the code 404 (NOT FOUND) or 400 (BAD REQUEST) is usually returned.

• GET http://www.example.com/api/v1.0/users
  (return a list of users)
  
• GET http://www.example.com/api/v1.0/users/ellen
  (return user information with id ellen)
  
• GET http://www.example.com/api/v1.0/users/12345/orders
  (return a list of user orders with id ellen)

HTTP PUT

HTTP PUT is commonly used to provide the ability to update a resource. If the PUT request succeeds, the code 200 is returned (or 204 if no value was given for the update). It is worth noting that the PUT request is unsafe since it modifies the resources on the server-side. But by sending data using the PUT method, the data will not disappear, it will be located where it was before, and repeated execution of the PUT request will not change the general state of the system.

• PUT http://www.example.com/api/v1.0/users/ellen
  (update user data with id ellen)
  
• PUT http://www.example.com/api/v1.0/users/ellen/orders/12345
  (update order data with id 12345 for a user with id ellen)

HTTP POST

The HTTP POST request is most commonly used to create new resources. Traditionally, it is used to create nested resources. In other words, when creating a new resource, a POST request is sent to the parent resource. Thus, the service takes responsibility and establishes the connection of the created resource with the parent resource, assigns an ID to the new resource, etc. Upon successful creation, an HTTP code 201 (or possibly a code 202 if the system is running background tasks to actually create the object requested) is returned, and the address of the created resource is also transmitted in the ‘Location’ header. 

POST http://www.example.com/api/v1.0/customers
(create a new resource in the customers’ section)

POST http://www.example.com/api/v1.0/customers/ellen/orders
(create an order for a resource with id ellen)

HTTP DELETE

HTTP DELETE is used to delete resources with a specific id. Upon successful deletion, the status 200 (OK) is returned. It is also possible to use status 204 (NO CONTENT) without the response body.

• DELETE http://www.example.com/api/v1.0/customers/ellen
  (remove a resource with id ellen from customers)
  
• DELETE http://www.example.com/api/v1.0/customers/ellen/orders/10 (delete an order with id 10 from a resource with id ellen)

REST API Subtypes

The Rest API has the 3 most used formats for providing resources. Sometimes they are called a subtype.

• REST API XML – This format is similar to the earlier method used by the SOAP (Simple Object Access Protocol) specifications.
• REST API JSON – This format is used when employing a text format for data exchange based on JavaScript. This format is the most widely used currently.
• REST API GraphQL – This format was designed to address the need for more flexibility and efficiency. It is the newest and most popular specification method.

There are quite a few popular topics about which one is better to use and why, as well as numerous comparisons to use.

Conclusion

In this tutorial, we have learned about the REST, API, and RESTful API concepts. We have explored what it is, what they are used for, and how they are applied. The interaction methods used in REST API is a rather broad concept, and there are no exact specifications. Finally, we learned that REST API is not a standard in or of itself, but an architectural style used for component interactions. For further study, we recommend a more in-depth examination of REST API JSON and REST API GraphQL methods and applying it use in practice.

Our Support Teams are full of talented Linux technicians and System administrators who have intimate knowledge of multiple web hosting technologies, especially those discussed in this article.

If you are a Fully Managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server or a Dedicated server owner and you are uncomfortable with performing any of the steps outlined, we can be reached via phone @800.580.4985, a chat or support ticket to assisting you with this process.