REST Architecture : Philosophy, Design, Benefits
Few months ago I’ve written a comprehensive answer explaining REST architecture on Quora- What are RESTful APIs and How do they work ?
I think it’s worth sharing here –
RESTful APIs are application programming interfaces that adhere to architectural style of REST architectural pattern.
The REST architectural pattern is defined by this paper – Representational State Transfer (REST) by Roy T. Fieldings
I will summerize this in simple terms as follows –
Constraints of REST Architecture
The constraints, which must be followed to call an architecture as “REST Architecture” are as follows –
Client Server Architecture
This is ‘default’ architectural style for ANY web application, which essentially separates user interfaces from data persistence concerns.
Now this is key constraint understanding REST.
This essentially means, Server does NOT care about STATE of the client, and vice versa!
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
Means, NO SESSIONS AND COOKIES!
It means, creating a uniform interface between client and server, for the interactions between them, and
Decoupling implementations from the interfaces-
means, implementation of the business logic should not depend upon it’s interface.
(concrete example: your routes in a web app must not change when you change logic of how the controller (or the business logic) is implemented)
Typically, HTTP is used to implement a uniform interface (using HTTP methods), as HTTP is a stateless protocol.
But that does not mean one must use HTTP to implement REST, any stateless protocol can work, for that matter.
The application should be layered – with each layer having it’s own responsibility, with ‘closed layer architecture’
This enables implementation of services like caching.
Data Elements of REST Architecture
Any information that can be named can be a resource
REST uses a resource identifier to identify the particular resource involved in an interaction between components.
(the table is collected from the research paper mentioned above)
Now when your system is following these constraints, you can call it a RESTful system, and an API (Application Programming Interface) (more generally called as web services in the context of web development) built using a backend with RESTful architecture are called REST APIs.
Now, building a system which implements ‘purest’ form of REST architecture, might sound like a herculean task.
Leonerd Richardson has defined different maturity levels for the REST architecture, which is explained in this article my Martin Fowler, here- Richardson Maturity Model , which breaks down principle elements of REST approach in three steps.
Richardson Maturity Model
The maturity levels can be described as –
Level 0 – The Swamp of POX (or POJ!)
It’s typically based on RMI (remote mehod invocation), it simply means, invoking a particular method in the backend with a service call.
Level 1 – Resources
This is first step towards the glory!Everything is provided as a named ‘resource’ (see the definition in REST elements section) with an appropriate identifier.
Level 2 – HTTP Verbs
This involves using appropriate HTTP verbs for the interaction. Examples of popular methods being –
HTTP GET to ‘get’ the information,
HTTP POST to change the information on server.
DELETE to destroy the data on the server identified by resource.
(find more on http://www.w3.org/Protoco
Also, this means usage of right HTTP response codes, for example.
- Informational messages – 1XX
- Success response – 2XX
- Redirection responses – 3XX
- Client error responses – 4XX
- Server error responses – 5XX
Commonly used status codes –
200 – OK , 206 – partial content
301 – moved permanantly
404 – not found, 403 – forbidden, 400 – bad request
500 – internal server error, 503 – service unavailable
Level 3 – Hypermedia Controls
Now this gets interesting!
To my understanding, this simply means, designing an API, in such a way, that API will provide hypermedia controls (links / URIs etc) that will allow further discovery of resources by client! Isn’t that fascinating?
Now, if you’re following this, you’re building a RESTFul system.
Roy Fieldings has subtly mentioned that RMM Level 3 is precondition for REST!
Now the benefits you can achieve by building a RESTFul system are tremendous!
Benefits of REST Architecture
Only Scalable Architecture can take advantage of Scalable Infrastructure!
This is especially holds true for today’s cloud based applications and their scalability demands!
REST architecture benefits for exactly that! Scalable architecture! With layered, n-tier system, it’s really easy to scale up RESTful system, with load balancers, caching, than a typical, session oriented, stateful system.
This is really a fancy way of saying – “systems that can serve any type of client”
This benefit comes from the client server decoupling and statelessness. The RESTful system does not depend upon the type of the client in any way.
RESTful API can be consumed by ANY type of client, for example, a web app, a smartphone application, or an embedded device, or any other server environment. This means it can be easily plugged with ANYthing else!!
That’s super awesome, right?
Independent Evolution of Client and Server
Client and server applications can be developed INDEPENDENTLY, that means, the evolution or changes in one does not affect implementation of the other.
Practically, you can have two different teams working on a backend and a frontend, or you can change or replace backend / frontend without breaking other.
This is a huge win especially for distributed teams.
REST architecture, esp. one with RMM Level 3, empowers the client and gives it intelligence and more responsibility than traditional stateful clients.
We live in the era where FAT Client – THIN Server architecture is gaining popularity, because of technological evolutions like Internet of Things or Ubiquitous Computing (intelligent clients being it’s primary constraints); in this era, REST architecture is huge win for anyone doing these things.
I believe this would help you to build a good RESTful APIs!
Hope this helps!
(And thanks for reading to the end!)