API (REST)

There are countless applications. And many, many times, business requirements require that these applications possess or provide functions of other applications. We thus have applications that communicate with others, mutually transferring data to offer a comprehensive experience or service. An example of this is Cabify, which consumes Google API data for the map.

Currently, the standard for this communication and data transfer are APIs. API stands for Application Programming Interface. And what is an interface? In this case it is simply an intermediate abstraction layer between two applications.

We had already established in a previous publication that programming is the science and art of giving instructions to machines. Well in this case, An application programming interface or API is an interface that allows one application to give instructions to another application. For example, a web or frontend application can give instructions to it’s server through it’s API (the server’s API).

Now, a REST API, or RESTful API, is an API that fits within the limits of the REST architecture.

And what is this REST architecture? Created by the Doctor in Information and Computer Sciences, Roy Thomas Fielding, who explains it in chapter 5 of his dissertation Architectural Styles and
the Design of Network-based Software Architectures in great detail is nothing more and nothing less than a set of guidelines for designing and developing an API in a specific way.

REST is an acronym for “Representational State Transfer”. Transfer of what? Representational state, that is, representations of the state of the web resources that we are serving to the world. Why representations? Because data from such resources is usually represented in formats such as JSON or XML.

Thus, a web resource could be the sales products of an e-commerce such as “falabella.com”, for example, a specific smart TV that Falabella wants to sell. This smart TV has data on its characteristics stored in a database. Features such as brand, size, weight, incorporated technologies, image quality, stock and price among others. These stored characteristics are, as a whole, the state of a specific moment of the smart TV. If the price, or the stock, or any of its data changes, the status of the resource changes.

Then, what a Falabella REST API that served this resource would do would be to allow the transfer of states of our smart TV, sending, receiving and/or modifying its data as information, that is, the state of this smart TV, to and from clients (front end applications) using HTTP methods (GET, POST, PUT, PATCH, DELETE, among others) in a specific format (a representation) (JSON or XML).

A basic API allows these CRUD operations on the resources it offers to be consumed.

In closing, the short story is that if you want to get into the backend, you will probably build or work on APIs serving data to the frontend. If you want to dedicate yourself to the frontend, you will be consuming data that an API serves you from the backend, and if like me, you dare to dedicate yourself to being fullstack, you will have to do both. Remember, the earlier you start in your life, the better it will be for you. And if like me, you made a career change after your 30s, just work, study and program hardly enough. Allegro ma non tropo. And slowly but surely.