REST stands for Representational State Transfer. A Yahoo or Google search on “REST web services” brings up tons of information. But if you are like what I was a few weeks ago – you will probably find all that information more annoying than helpful, because you want to create a REST web service in a hurry. We have, consciously or not, all become very used to tailor made instructions from the internet – and we love nothing more than a step by step guide to do something. Evil as much as it is, a “how-to” guide is all we love to dig out. In this particular web search, I was denied just that.
Soon I found out that writing a REST web service has no shortcuts – you have to first fully understand what REST is. I have a wonderful analogy – think of a C++ or JAVA or .NET newbie trying to find a spoon feeding article on “How to do object oriented design”. Well, good luck! REST is just that – experts coin it as an “architectural style” – but I am writing this article in my own words, so I will steer clear of stuff that confused me in the first place. I think REST is where architecture and design merge, and the thin line between the two disappears.
Let us get straight to business. I will start with what a traditional web service developer who has no idea about REST needs to know. I will not start shooting jargons at the beginning, which is like attempting to create method from chaos. Instead, I will stay methodical the whole way.
This article is Part 2 in my series on REST web services. While the first article introduces REST web services, this one takes us through the process of designing a RESTful web service