Blog Single

UNDERSTANDING REST APIs

In this article, we will talk about everything one needs to know about REST APIs to be able to read API documentations and use them effectively.

What is A REST API?

An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer creates the API on the server and allows the client to talk to it.

REST determines how the API looks like. It stands for “Representational State Transfer”. It is a set of rules that developers follow when they create their API. One of these rules states that you should be able to get a piece of data (called a resource) when you link to a specific URL.

Each URL is called a request while the data sent back to you is called a response.

Why Rest API?

Rest mostly came into popularity due to the following reasons:

• Heterogeneous languages and environments – This is one of the fundamental reasons which is the same as we have for SOAP API as well.
• It enables web applications that are built on various programming languages to communicate with each other
• With the help of Restful services, these web applications can reside on different environments, some could be on Windows, and others could be on Linux.

SOAP vs. REST 

EXAMPLE

Consider a scenario where you are using the Book My Show app. Now, obviously, this application needs a lot of Input data, as the data present in the application is never static. Either movies getting released on a frequent basis, or various sites showing different languages movies at various times of the day. 

This data is received from the Server also known as a Web-server. So, the client requests the server for the required information, via an API, and then, the server sends a response to the client. Over here, the response sent to the client is in the form of an HTML Web Page. 

As one would prefer the data to be returned in the form of structured format, rather than the complete Web page.

So, the data returned by the server, in response to the request of the client is either in the format of JSON or XML. Both JSON and XML format have a proper hierarchical structure of data.

But, the issue which is present in this framework till now is that you have to use a lot of methods to get the required information. To the fact, using these methods to retrieve information becomes quite cumbersome when you require complex data.

So, this is where REST API comes into the picture. The REST API creates an object, and thereafter send the values of an object in response to the client.

Architectural Constraints of RESTful API: 

In order for APIs to be RESTful, we have to follow a set of constraints when we write them. The REST set of constraints will make the APIs easier to use and also easier to discover.

There are six architectural constraints which makes any web service are listed below:

• Uniform Interface- It is a key constraint that differentiate between a REST API and Non-REST API. It suggests that there should be an uniform way of interacting with a given server irrespective of device or type of application (website, mobile app).

• Stateless- It means that the necessary state to handle the request is contained within the request itself and server would not store anything related to the session. In REST, the client must include all information for the server to fulfill the request whether as a part of query params, headers or URI.

• Cacheable- Every response should include whether the response is cacheable or not and for how much duration responses can be cached at the client side. Client will return the data from its cache for any subsequent request and there would be no need to send the request again to the server.

• Client-Server- REST application should have a client-server architecture. A Client is someone who is requesting resources and are not concerned with data storage, which remains internal to each server, and server is someone who holds the resources and are not concerned with the user interface or user state. They can evolve independently. Client doesn’t need to know anything about business logic and server doesn’t need to know anything about frontend UI.

• Layered System- An application architecture needs to be composed of multiple layers. Each layer doesn’t know any thing about any layer other than that of immediate layer and there can be lot of intermediate servers between client and the end server. Intermediary servers may improve system availability by enabling load-balancing and by providing shared caches.

• Code on Demand- It is an optional feature. According to this, servers can also provide executable code to the client. The examples of code on demand may include the compiled components such as Java applets and client-side scripts such as JavaScript.

Methods of REST API

The method is the type of request you send to the server. You can choose from these five types below:

GET- Retrieves one or more resources identified by the request URI and it can cache the information receive.

POST- Create a resource from the submission of a request and response is not cacheable in this case. This method is unsafe if no security is applied to the endpoint as it would allow anyone to create a random resource by submission.

PUT and PATCH- These two requests are used to update a resource on a server. If you perform a PUT or PATCH request, the server updates an entry in the database and tells you whether the update is successful. In other words, a PUT or PATCH request performs an ‘UPDATE’ operation.

DELETE- Delete an existing resource on the server specified by the request URI. It always return an appropriate HTTP status for every request.

These methods provide meaning for the request you are making. They are used to perform four possible actions: 

Create, Read, Update and Delete (CRUD).

Comparison between a Patch and an Update

REST APIs- SECURITY THREAT

Every web and mobile application out there is powered by APIs. By nature of the APIs, many of them have a direct line to the heart of the user data and the application logic.

For example, getting control of the billing API would allow a hacker to redirect payments to his/her own accounts or mark purchases as completed, while the actual payment has not been received. Substituting a malicious or phishing API for a legitimate one can result in whole sites being taken over.

Here at RestCase, we believe that the best security is preventive security. When we auto-generate security tests for API, the first thing we are testing is the Man-In-The-Middle attack (MITM).

MITM attacks occur in two stages: Interception and Decryption.

Here are 2 recommendations that will make your REST API more secure:

1. HTTP and Lack of TLS

The absence of a Transport Layer Security (TLS) in an API is practically equivalent to handing out open invitations to hackers. Transport layer encryption is one of the most elementary ‘must-haves’ in a secure API. When secured by TLS, connections between a client and a server have one or more of the following properties:

• The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted.

• The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.

• The identity of the communicating parties can be authenticated using public-key cryptography.

• The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

2. Use Strict Transport Security

Forcing SSL should be combined with HTTP Strict Transport Security. Otherwise, you run a risk of users entering your domain without specifying a protocol.

For example: 

typing example.com rather than https://example.com and then being redirected to HTTPS. 

This redirect opens a security hole because there’s a short time when communication is still over HTTP.

You can address this by sending an STS header with your response. This forces the browser to do the HTTP to HTTPS conversion without issuing a request at all. Instead, it sends the header together with a time setting that the browser stores, before checking again:

strict-transport-security:max-age=315660000;

This means that the header is set for 10 years and includes all subdomains.

If you follow these simple two guidelines, it will make your REST API much more secure and less vulnerable to attacks.