In a bloated world of world wide web the biggest issue is "interoperability". Don't let anyone distract you from this point. It would be imprudent to assume that islands of isolation is what makes web a happening place.
SOAP has been around for a while and has proven it's grit with several enterprisy solutions; implemented successfully. And while SOAP has given it's run for money; it's time to catch some REST.
I am no expert on either subjects; but from my superficial understanding of both I'm going to delve into a bit of "What is REST?" and "What does REST brings to Table?" What are the primary differences between REST and SOAP. And while I am doing "all that"; I'll try to suggest that REST is more suitable than SOAP for most applications; but don't you go and buy my garbage; until you see for yourself.
So lets get rolling.
What's up with RESTing anyway?
RESTful design is not a standard. It's like a architectural style. Somewhat like Client-Server analogy; which is again not a standard but a design choice. REST leverages existing features/methods of HTTP as it works gracefully over it. That is one severe lacking of SOAP. It fails to harness the HTTP capabilities to it's optimal level. And thats what I think; is a big drawback in complex and "enterprisy" solution; as you often build those things ground up; which otherwise could have been used; if HTTP and it's features were used properly. More on that as we get our hands dirty with details. Oh and by the way, REST stands for Representational State Transfer. Thats so, because as you request resources from a system; it changes it's state to pass back the information and so it's basically passing you back the representational state. Which is why R.E.S.T
What does REST brings to Table
My one word answer to that is "Simplicity".
I wanted to go with "A lot", but figured; maybe that won't go down as 'one word answer'. Now to answer that question; as to what does really REST brings to us; think of yourself surfing a website. You see information and you see links. Each link (when clicked) transforms the page into a portal which provides you more detailed/relevant information. It is not so in web services between disparate systems. You need to be explicit, have pre-defined formats and make appropriate calls to get information which is limited to services conceived notion of "what is expected with a call to this service?"
I hope you are following.
Now think that you want to bring the browsing experience to web services. Can you do that? Of course you can do that. It just needs some smart programming with SOAP and voila. But what if you can escape a big chunk of that programming to inculcate browser like experience in your web services; instead you use existing capabilities of XML, HTML, URL, HTTP, Http header etc.
Here is a small logical example to clear things up in more detail. But before I do that; here are the REST rules:
- Everything is represented as a resource and you perform operations on a resource. So for example if "post" (on a blog) is a resource then http POST means you are trying to create a new post; a GET operation means, you are trying to fetch a post, a PUT request means update and a DELETE request means you want to delete. (So now the http request TYPE defines the operation)
- A base URL + a NOUN represents a resource and thats how operations are done on it. For example for a blog post a possible URL can be http://www.slymonkey.com/post/1
- A GET request would always either provide a list of resource type specified or will provide a detailed info if requested with appropriate id.
- Each response would contain a way to navigate to more details. This would be achieved by either including URLs with appropriate resource ids embedded or other standard formats. (this is req. only if more details can be possibly fetched. A small example to showcase in a bit)
- Describe how services need to be invoked? WSDL or HTML?
- Specify a response formate (DTD, W3C schema etc) for a POST/PUT response. (If a service accepts POST/PUT response)
A simple example now.
Assume a simple service with maintains electronic gadgets. It provides options to list the gadgets, get gadget details and option to view technical specifications. Also a new order can be placed and updates to order can be done.
- Getting listing of gadgets: http://dumb-gadget.com/gadgets
- A response to above GET request may look like this. If you'll notice the url for detail about each gadget is provided alongside. These urls can provide more information about each gadget and each of those request will be a GET request but for a specific resource rather than listing as it provides ID of the resource in the URL.
- The response for each gadget details could in turn contain URL for more detailed technical specifications in appropriate section.
As you can see that this approach actually simulates a browsing kind of experience in web-service. And only development of code that you have done is, handling web service requests in a REST format of resource and http Request TYPE. If you do that; rest should fall into place already.
Now if you wanted to create an order; you could fill the details in an XML and do a POST for the resource "Order" and system would know that you are trying to create an order. Another simple way would be, as displayed by following URL:
http://dumb-gadget.com/gadget/100/order
If the above mentioned URL is accessed in POST way, then it would explicitly mean that a request is being placed to place a new ORDER for GADGET with id 100. Order could contain all details like quantity and other miscellaneous attributes; however gadget id may not be required as that would be understood by service looking at the URL.
I presume that now you see; how we are leveraging HTTP request types and URLs to specify things explicitly. And this is not even the beginning. :)
Here are other things that we often forget about HTTP; when we talk in web service terms:
- Caching: Http supports caching so you can mark your responses as cachable if you want to. That would hold up repeated requests to server if the last provided data is not yet expired as set by you. This is especially good for system where data change is not very frequent; instead it's a ad-hoc lookups that system serves.
- Uniform interface: No new protocol, no new standards. HTTP, URL etc is know well globally.
- MIME Types to specify the response type. The client can now render based on HTTP headers the response appropriately.
- Proxy, Firewalls, Gateways and other security guidelines may be imposed without any issues. This leads to a layered architecture without any change in contract or any knowledge to client as to how it is dealing with the server. This is especially because everything rides on HTTP protocol.
Now that I have managed to blabber so much about REST; I must mention once more, "explicitly", that REST achieved everything that SOAP does and with much more simplicity and much more optimal usage of existing capabilities. However that does not mean that REST is the blind solution to everything and SOAP can he de-commissioned here on and considered dead.
I still personally feel; that SOAP is a good choice when you have complex types in contract. Complex types can be returned with SOAP and works well. Although it's always a good idea to break complex types into simpler primitives and use REST; but that may not be possible always and in those cases SOAP is a decent choice.
I am sure there are more intricacies on comparisons of SOAP and REST; but this was my general and a very high level take on it; especially for those, who are just getting started with REST or want to get started.
For a comprehensive text on REST please refer Roy Fielding's Dissertation on REST
