"What is REST?" - One persistent question I asked in last 100+ interviews taken. I got various replies like its a protocol, its the way APIs communicate, some compared it to SOAP, some said its GET,POST...The responses did not come as a surprise - just like many other ill-defined terms in Software Engineering - from Architecture to OOPS to SOA to Microservices and now Cloud Native to name a few - REST as well is part of the 'ill-defined terms' family.
Today we continue to struggle with developing and maintaining distributed systems, while at the same time we have this seamlessly working, largest, scalable, flexible distributed system ever created - WWW. - The World Wide Web.
Remember 2020, when the lockdown happened and suddenly there was a surge in web traffic - with all people going online - schools, offices etc., the web continued to work seamlessly and ensured the show kept on going. What if we could design our software with same reliability and scalability?
"The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?" - Alan Kay (pioneer of object-orientation, co-designer of Smalltalk)
What makes Web work so well? REST provides an answer to it and can act as our guide to design any distributed system - that requires to be long-lived as the Web.
REST was coined by Roy T. Fielding in his PhD. dissertation - probably the most read one ever (who reads them apart from the writer and the evaluator ;))
REST is an Architectural Style for Web based Distributed Systems
Architectural Style is a set of constraints defined to retain specific Software Engineering Principles. We could implement different architectures based on an Architectural Style. Take a drive through Delhi or Agra you can immediately recognize the Mughal Architectural style by looking at any of the old buildings. While at the same time the architecture (layout, material used, aesthetic design) is different for each.
REST is built upon the constraints from existing Architectural styles with an additional set of new constraints. Constraints are a set of rules that ensure that the design meets the required expectations. For example, the constraints of safety regulations, cost, fuel efficiency are applied on the design of the car you are driving.
Constraints adopted in REST from other architectural styles include: Client-Server, Stateless, Cache, Layered system and Code on demand. These ensured the retention of software engineering principles - Separation of concerns, Reliability, Scalability, and Extensibility - in the REST architectural style
New constraints - to ensure uniform interface between components - differentiates REST from other Architectural styles. These constraints apply on Components (their role), b) Connectors (interaction between components) and c) Data (interpretation of data that flows between components). For example, in REST APIs the use of standard HTTP methods (GET, POST, PUT, PATCH, DELETE) to perform CRUD (Create, Read, Update, Delete) operations on resources identified by unique URLs ensures uniform interface for different clients to interact with web services.
The constraints - defined by REST Architectural Style, can help create components that are easy to understand, maintain, and use, and that can easily adapt to changing requirements or technologies. They also ensure that the components are scalable, reliable, and interoperable, which is essential for building large-scale, distributed systems.
I hope this article helped demystify some elements around REST.
References
Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.