REST

REpresentational State Transfer - An architecture style based on the principles that make the "web" work.

About REST

TBD

Why REST

REST tries to bring back [Simplicity] into the web services game. This [ArchitecturalStyle] goes back to the drawing board to rediscover the [FundamentalPrinciples] that make the web to work and so very well. To connect and to be connected to another [WebServer] or [WebResource] on the internet is relatively quite easy. However, the first generation of Web Services have turned out to be very complicated requiring a lot of code, human resources and computing resources. The barrier to providing and consuming web services was just way too high.

What was touted as the technology that would enable organizations to rapidly exchange information only somewhat succeeded since the majority of the [LongTail] of organizations were left out. The organizations that had deep pockets and committed to the vision could persevere and reap benefits. But many of the other organizations tried and failed with dashed hopes and investment losses. Disillusionment was everywhere. Chaos reigned.

While Chaos reigned, like life's wonderful innovations, Order was emerging. While Chaos jeered, Order cheered. Order was at work at different corners of the world, encouraging the believers that there might be a better way, a simpler way. RoyFielding pioneered this thought with his seminal thesis. [Jetty] - the little [WebServer] that could became the engine. JeromeLouvel , challenged, experimented by creating the [RestLet] framework. People who examined his code and proposition claimed "But I could do that too, that is no big deal!". And that exclamation marks the realization that maybe, Order is indeed ushering a challenger - A David in a domain ruled by Goliaths, for Goliaths and of Goliaths.

The Davids started working more feverishly. The customers liked the quick results and the intuitiveness of the services. Google demonstrated the value of Mashups. Services via the web became easy to consume and create. Non-programmers realized new ways of copy-pasting and duplicating patterns to "hack" new applications. It was apparent that LessIsMore and [SmallIsBeautiful] and [SizeDoesNotMatter]. http://Deli.cio.us took off, so did http://flickr.com . Amazon, eBay and other major [WebServices] players started abandoning the opaque, mystifying ways of the older generation web services protocols. The newer generation of customers demanded lighter, simpler way to produce "services on demand". Success bred success. The David's multiplied, the Goliaths got cornered. David's grew and started to fight - among themselves. Chaos started rearing its head again.

Order, this time around, could not wait. She prevailed on the thought leaders. Wait said a few, lets understand why REST works. Let us explore its power, its fundamental principles, its atomic primitives. What is REST? [DeepRest] and other differentiating concepts started emerging. [RestFul] became a term to describe a general class. Thoughts about [FriendlyUrls] , [HackableUrls] , [UriAsApi] started converging into literature that talked about making things work in a web services world. Chaos and Order prevailed together, confusing, enlightening, questioning, answering - all at a same time. Things looked messy. Things looked rich. Things looked real. That was then, and it is still now. Its an exciting world.

Fundamentals of [RESTfulArchitecture] , or REST in general

TBD

References

#RoyFielding's thesis
#Arun is reviewing this book on web services based on REST architectures.
#[RestLet]
#[NetKernel]
#Jetty