REST – Representational State Transfer

REST comes from Roy Fielding’s PhD paper, published in 2000, and it stands for Representational state Transfer. REST is set of architectural constrains which can apply on application design to make application more scalable, flexible, reusable, loose couple and align to business agile. Fielding’s REST guideline defines the specific role for data, component, operation, communication protocols, data consumer and producer.

REST is generic constraints for distributed technologies with no limits of technologies or stack.

Following are the constraints that define a RESTful system.

• Should be for distributed system
• Data communication should be stateless
• Request should be independent and reusable
• It has to support caching.
• System should be access uniformly accessible
• Desperate representation of  response
• Standardize operations

These are independent of technology and represents how data communicate between and what’s guideline need to follow during data transfer between distributed systems.

e.g. Static web is RESTful as it follows fielding’s key guideline on REST. For instance, the existing static web  provide caching, stateless connection, the unique link to resources (HTML). On the other hand, traditional dynamic web applications haven’t always been RESTful, because they typically break some of the outlined constraints. For instance most dynamic application is not stateless.

But we can use abstraction on dynamic system that makes a RESTful system using HTTP protocols, URIs, representation and resources.