what really are rest API's?

learning web development, you've probably come across the term REST,RESTful services or REST API once or twice and you may have thought, "what really is rest?", this article will give you a basic overview of what REST is and what it is used for.

What is REST API? The term REST stands for REpresentational State Transfer. It is an architectural style that defines a set of rules in order to create Web Services. In a client-server communication, REST suggests to create 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 for a movie in Bangalore at a certain place and time, then you can create an object on the server-side.

So, over here, you have an object and you are sending the state of an object. This is why REST is known as Representational State Transfer.

The architectural style of REST helps in leveraging the lesser use of bandwidth to make an application more suitable for the internet. It is often regarded as the “language of the internet” and is completely based on the resources.

For example, when a developer calls Instagram API to fetch a specific user (the resource), the API will return the state of that user, including their name, the number of posts that user posted on Instagram so far, how many followers they have, and more. The representation of the state can be in a JSON format, and probably for most APIs this is indeed the case. It can also be in XML or HTML format. What the server does when you, the client, call one of its APIs depends on 2 things that you need to provide to the server: An identifier for the resource you are interested in. This is the URL for the resource, also known as the endpoint. The operation you want the server to perform on that resource, in the form of an HTTP method, or verb. The common HTTP methods are POST (create), GET (read and consult), PUT (edit) and DELETE.

There are six key constraints to REST API design to be aware of when deciding whether this is the right API type for your project: Client-Server The client-server constraint works on the concept that the client and the server should be separate from each other and allowed to evolve individually and independently.

Stateless that calls can be made independently of one another, and each call contains all of the data necessary to complete itself successfully. A REST API should not rely on data being stored on the server or sessions to determine what to do with a call, but rather solely rely on the data that is provided in that call itself. Identifying information is not being stored on the server when making calls. Instead, each call has the necessary data in itself, such as the API key, access token, user ID, etc.

Layered System layered system is a system comprised of layers, with each layer having a specific functionality and responsibility. If we think of a Model View Controller framework, each layer has its own responsibilities, with the models comprising how the data should be formed, the controller focusing on the incoming actions and the view focusing on the output.

Code on Demand Code on Demand allows for code or applets to be transmitted via the API for use within the application. In essence, it creates a smart application that is no longer solely dependent on its own code structure.

Uniform Interface The uniform interface lets the client talk to the server in a single language, independent of the architectural backend of either. This interface should provide an unchanging, standardized means of communicating between the client and the server, such as using HTTP with URI resources, CRUD (Create, Read, Update, Delete), and JSON.

Cache Because a stateless API can increase request overhead by handling large loads of incoming and outbound calls, a REST API should be designed to encourage the storage of cacheable data. This means that when data is cacheable, the response should indicate that the data can be stored up to a certain time (expires-at), or in cases where data needs to be real-time, that the response should not be cached by the client. By enabling this critical constraint, you will not only greatly reduce the number of interactions with your API, reducing internal server usage, but also provide your API users with the tools necessary to provide the fastest and most efficient apps possible.