Two weeks back when I started reading about REST, there were thousands of articles available on Internet and after going through quite a many of them I finally found myself at the same position where I started. All of them were very informative but confusing as there were so many terms used like resources, verbs, nouns, blah blah blah…. I then decided to note down each term so that I can relate terms with each other while moving forward and gathered all the information below.
While working with traditional web services, we generally create web methods and expose them to our clients for their use. These web methods expects some kind of input from the client (in terms of string, integer, xml, etc.) in order to meet the required expectation.
Imagine a traditional web service which does not expose methods but exposes objects. An object does not have any input or output, which does not do anything because it is a NOUN not a VERB, a THING not an ACTION.
Let’s take an example of an automobile manufacturer ‘Volkswagen’ which exposes a method called ShowCarDetails( ). This method expects the car name as an input and gives the car details as output.
Think for an instance, in place of this web service, there is a new one which exposes car names as objects. So, when a client looks at it, instead of ShowCarDetails (), he will see POLO, VENTO, JETTA, PASSAT, etc. as objects. These objects don’t have any methods written for them to be invoked by clients. These objects (NOUNS) need to be acted upon with some action on them (VERB). In this case, in order to fetch the car details we will apply the GET (VERB) action on POLO (NOUN) to retrieve its details.
Think for an instance, in place of this web service, there is a new one which exposes car names as objects. So, when a client looks at it, instead of ShowCarDetails (), he will see POLO, VENTO, JETTA, PASSAT, etc. as objects. These objects don’t have any methods written for them to be invoked by clients. These objects (NOUNS) need to be acted upon with some action on them (VERB). In this case, in order to fetch the car details we will apply the GET (VERB) action on POLO (NOUN) to retrieve its details.
There is a term in OOPs called “Polymorphism” which says that a single verb can be applied to multiple nouns. This was the biggest challenge to identify the common verbs (actions) which can be applied to all the nouns (objects). HTTP was the answer for this. HTTP is a "Protocol" which says: a client can send a request to a server which is either a GET or a PUT or a POST or a DELETE (there are other verbs as well – HTTP 1.1 supports 8 verbs). The entire web called as INTERNET works on these verbs only. So, if a web service that exposes only objects supports these four operations "on its exposed objects", any client should be able to do anything with that web service! This is what is called as REST.
REST is basically a term introduced by Roy Fielding in his Ph.D. dissertation to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.
If we go by the definition:
“REST exposes resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information).”
In many ways, the largest current world Implementation of REST is the INTERNET. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
REST is not a standard. One can only understand it and design his web services in that style. While REST is not a standard, it does use standards:
- HTTP
- URL
- XML/HTML/GIF/JPEG/etc (Resource Representations)
- text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)
Now, going by the same example as used above, if we need to get details of Volkswagen car POLO we can get it by just using a URL as shown below (as an example):
"http://www.volkswagen.com/POLO"
When you will type this URL in browser, it will respond back to you with the required details in the pre-defined format as set up in the service (xml, text, json, etc.). Please note that the above URL will not actually work as this does not exist, I have used it as an example.
Much like Web Services, a REST service is:
- Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
- Language-independent (C# can talk to Java, etc.),
- Standards-based (runs on top of HTTP), and
- Can easily be used in the presence of firewalls.
Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But as with Web Services, these can be added by building on top of HTTP:
- For security, username/password tokens are often used.
- For encryption, REST can be used on top of HTTPS (secure sockets).
- ... etc.
One thing that is not part of a good REST design is cookies: The "ST" in "REST" stands for "State Transfer", and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.
Conclusion:
REST is an architectural style which says to expose resources or objects to the consumers of the web service and allows the basic HTTP operation to be performed on them. In the next part of an this article, we will see detailed description about REST and how to create your first REST service.
References:
Representational State Transfer
REST Tutorial by Dr. M. Elkstein
REST and the Real World
