2 comments

REST has been growing in popularity as the preferred way of publishing and consuming web services. REST has its origins in 2000 when Roy. T. Fielding introduced an architectural style and design for network control systems as part of his dissertation in U.C Irvine.  In academic terms, a RESTful architecture must comply with the following set of constraints –
–       Client Server Architecture
o  Clear separation of concerns with a modular approach to building systems where one entity publishes web services and one consumes them
–       Uniform Interface
o   Support heterogeneity of clients by exposing a uniform interface to the services, there by allowing clients and services to evolve independently of each other. Every resource is universally identifiable.
–       Stateless
o   Requests and Responses are self-contained and self-describing. Servers are stateless, thereby allowing for quick recovery from failures such as loss of requests or responses
–       Cacheable
o   Support for response caching at the clients or intermediaries, thereby improving scalability and performance
–       Layered
o   Support for proxies, gateways and other intermediaries between the clients and servers, allowing for the intermediaries to process messages before forwarding them on. The self-describing and stateless nature of the system would allow intermediaries to process the messages.
 
 
In simpler terms, REST is a set of guidelines and principles on how web services can be published and consumed over the Internet.  The common misconception is that it is a protocol and a standard. REST is neither a protocol nor a standard. It is however, standards based, thereby facilitating interoperability.  While REST makes no assumptions on the underlying protocol, HTTP is almost used universally as the underlying protocol for REST communications. Likewise, while there is no requirement on the data representation format, JSON is very popular as the data exchange format.
 
A lot of the popular services including Facebook, Twitter, Stripe, GitHub, Paypal and others today support a “REST” based API for developers to consume . With a lot of buzz around REST, everyone wants to to have a REST complaint API. However, a closer examination of these APIs would reveal that not all of them are truely RESTful.  Of course, it may not be always practical to model your resources and consequently, design an API that a RESTifarian would approve. Without a standard dictating what is allowed or disallowed, there is room for interpretation and consequently, there are variations in how these APIs are designed.
 
I recently gave a talk on REST API design at Self.Conference with the goal of describing the underlying principles that govern the design of RESTful APIs and the common anti-patterns to avoid. It discusses the approach to API Driven Development and  in fact, much of the content in the slides can serve as recommendations for API design in general .

The slides can be downloaded from here.