What is REST and why it’s the next BIG thing?
A long time ago I got that funny and heavy PC with Windows 3.1 in it. Every time when I boot the OS I had to enter WIN in CLI (Command Line Interface). A few years later I got an amazing Windows 98 with beautiful GUI (Graphic User Interface) and later on, I had a phone with TUI (Touch User Interface).
However, nowadays I am very passionate and enthusiastic about API (Application Programming Interface), specifically, REST API and that’s exactly what I am going to write about in this article.
Simply put, REST API provides an interface for Web applications or applications that need to connect to each other via the Internet to communicate.
You probably heard or read about REST API and you still trying to map it to your brain. Don’t worry, I have been there and I know exactly how do you feel.
The next big thing in the industry
“APIs enable companies to more easily build products and services that would otherwise take too long to build,”said Augusto “Aghi” Marietti, who is the CEO of Kong. “Developers can use these APIs to more easily access business-critical information and focus on other priorities instead.”
To date, there are over 22,000 public APIs that can be used to do everything from checking traffic and weather to updating your social media status and sending Tweets, to even making payments.
“We have taken the entire messy and complex world of telephony and reduced it to five API calls.”Jeff Lawson – founder and CEO of Twilio
In addition to the 22,000 public APIs, there are hundreds of thousands
more private REST APIs or APIs that are not available for consumption by
the general public. Those APIs are used by companies to extend their capabilities
and services across a broad scope of use-cases, including multiple devices.
One of the most common forms of a private cross-device REST APIs would
be an API written for a mobile application. Those APIs let the company transmit data to the app on your phone.
Since 2005, the use of Web APIs has exploded exponentially, and multiple Web formats and standards have been created as technology has advanced:
Now, when you know what API is, how much it amplifies businesses and how it’s not only the trend but a completely new way of building communication between applications, devices, and businesses let’s dive into six key constrains to REST.
What REST makes REST
Surprisingly, while most APIs claim to be RESTful, they fall short of the requirements and constraints asserted by Dr. Roy Fielding.
There are six key constraints to REST that you should be aware of when deciding whether or not this is the right API type for you.
The client-server constraint operates on the concept that the client and the server should be separate from each other and allowed to evolve individually.
REST APIs are stateless, meaning that calls can be made independently of
one another and each call contains all of the data necessary to complete
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.
The key to the decoupling client from the server is having a uniform interface that allows independent evolution of the application without having the application’s services, or models and actions, tightly coupled to the API layer itself.
As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility.
Code on demand
Perhaps the least known of the six constraints, and the only optional
constraint, Code on Demand allows for code or applets to be transmitted
via the API for use within the application.
Design first approach
Manufacturing is a popular metaphor for software development. […]Domain-Driven Design from Eric Evans (highly recommend)
This metaphor has messed up a lot of projects for one simple reason – software development is all design.
The Design First approach is a new approach but is quickly gaining adoption across API teams. It advocates for designing the API’s contract first before writing any code.
To design API we use the OpenAPI Specification. The OpenAPI Specification (formerly known as the Swagger Specification) has emerged as the world’s standard for defining RESTful APIs.
Planning your REST API
While understanding which type of REST API you are building is a vital step in creating the perfect one for your company – and one that users will love –
It is just as important to carefully plan out your REST API’s capabilities.
Surprisingly, while being one of the most crucial steps in API development,
this step is usually rushed through by companies excited to generate a
product map and start working on code.
In many ways, building an API is like building a house. You can say, “I want
my house to look like this picture,” but without the blueprints, chances are
it isn’t going to turn out exactly the way you had hoped.
Yet while we carefully plan and build houses, APIs have been plagued by the “agile methodology.”
Why Agile doesn’t work in building APIs?
Unlike many Software as a Service application built for today’s web, an API’s interface is a contract, and as such cannot be constantly changing. With increases in the use of hypertext links and hypermedia, perhaps someday in the future, that may no longer be true.
Right now many developers are hardcoding resources and actions and as such changing the resource name, moving it or changing the data properties can be detrimental to their application.
Since we now know that the API interface is a contract that means that it does not suppose to be changed so often. We really want to make sure we spent most of the time designing and going through the cycles as many times as we need to get the best design for our development.
Personally, I believe that the REST API is the next big thing in the industry. Even from the perspective of the developer, I see how companies today building web applications – mostly as a REST API with multiple client applications. Also, I saw some old monolith applications that got rebuild as REST APIs in a few companies where I have worked.