Mastering REST Architecture — REST Architecture Details

In our last post, we’ve learned about REST, REST API and RESTful Web Services terms and now we’ll learn REST Architecture with its details.

REST — Representational State Transfer

REST stands for Representational State Transfer (It is sometimes spelled “REST”). It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

REST is a simple way to organize interactions between independent systems.

HTTP — HyperText Transfer Protocol

HTTP means HyperText Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.

We use HTTP protocol thousands of times in our daily life!

HTTP is the protocol that allows for sending documents back and forth on the Web. And, REST is the architecture that uses HTTP protocol to provide functionalities depends the requirements of software applications or Web pages in a very light-weight, simple and effective way!

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

HTTP requests example

Benefits of using REST Architecture

Here are 5 benefits of using REST architecture:

• RESTful as lightweight Web Services: The RESTful architecture was a reaction to the more heavy-weight SOAP-based standards. In REST web services, the emphasis is on simple point-to-point communication over HTTP using plain XML. In addition, RESTful permits many different data formats whereas SOAP only permits XML.
• The simplicity of RESTful: The RESTful architecture is much simpler to develop than SOAP. One of the main reasons for REST popularity is the simplicity and ease of use, as it does an extension of native Web technologies such as HTTP.
• RESTful architecture is closer in design to the Web: RESTful is the architectural style of the web itself, so the developer with knowledge in web architecture will naturally develop in the RESTful architecture.
• Scalability: As RESTful forbids conversational state, which means we can scale very wide by adding additional server nodes behind a load balancer.
• Expose APIs as HTTP Services: When developers need the universal presence with minimum efforts, given the fact that RESTful APIs are exposed as HTTP Services, which is virtually present on almost all the platforms.

Client context is never stored on the server between requests. Each request has to contain all the necessary information. A stateless server improves scalability by allowing the server to quickly free resources and simplifies implementation. Reliability eases recovering from partial failures. Visibility, monitoring system does not have to look beyond a single request to determine the nature of the request.

Architectural Constraints

Here are 6 REST constraints that we can consider as design rules, that must be applied to establish the distinct characteristics of the REST architectural style. In other words, These 6 architectural constraints which make any web service — a true RESTful API:

• Interface / Uniform Contract: Once a developer becomes familiar with one of your API, he should be able to follow the similar approach for other APIs.
• Client-Server: Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.
• Stateless: No client context shall be stored on the server between requests. The client is responsible for managing the state of the application.
• Cache: Well-managed caching partially or completely eliminates some client-server interactions, further improving scalability and performance.
• Layered System
• Code-On-Demand (optional)

All above constraints help you build a truly RESTful API and you should follow them. Still, at times you may find yourself violating one or two constraints. Do not worry, you are still making a RESTful API — but not “truly RESTful”.

Each constraint is a pre-determined design decision that can have both positive and negative impacts. An architecture that eliminates a required REST constraint is generally considered to no longer conform to REST.

Conclusion

• REST is an architectural pattern which is based on HTTP and uses HTTP requests, responses, verbs and status codes to communicate.
• The fact that REST services use HTTP means they can be consumed by almost any ‘online’ device or application (including IoT devices such as toasters, cars, pedometers etc) — no proprietary knowledge of the API is required! This is freaking awesome!!!

REST is a cool phenomena of Web Technologies and it always makes me excited to develop light-weight and robust systems that are built on top of REST Architecture to interact using Web!

Well, we’ve learned the REST Architecture details, benefits and constraints… And, in our next post we’ll learn about REST API details, its advantages and its constraints. We’ll move forward to develop practical projects in different high-level programming languages (java, python, .net core) using different frameworks (Spring Boot, Ruby on Rails, WEB API) to get the main philosophy and main practical usages of REST Architecture that we’ve already built its theoretical background via “Mastering REST Architecture” short tutorial series!