Why RESTful over SOAP (almost always)?

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:

1. 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)
2. 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
3. A GET request would always either provide a list of resource type specified or will provide a detailed info if requested with appropriate id.
4. 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)
5. Describe how services need to be invoked? WSDL or HTML?
6. 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

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Thunderbird Plugins

Finally dark ages are over and we have got rid of notes. Of all the desktop email clients I have had to use (corporate level); I have hated the Lotus Notes most. I will never understand how it managed to survive so long in market.

Thoughtworks is officially on cloud and we have migrated to robust Google solution of apps on cloud. Gmail, Google docs, Google Calendar.. the whole nine yards. And who knows; maybe in foreseeable future, google wave!

Funny part of this transition is that; while I was looking forward to move to gmail due to it's feature rich nature; as soon as I moved to gmail; I craved for a desktop client to manage emails. I know; I don't need one; but I guess it's just become second nature to classify corporate email accounts with thick desktop clients. So I downloaded Thunderbird.

It's an excellent desktop email client. It took a while to set it up with all the plugins; but once I was done; I was really happy with what I accomplished. Here is a comprehensive list of plugins that I used to set my thunderbird up; to enable personalization to a great extent and to peak my productivity:

• CS Lite: Cooke manager add on for using thunderbrowse successfully.
• Thunderbrowse: To enable a web browser within the email client. Saves me trouble.
• Google Contacts: To sync all contacts from my google address book.
• Lightning: To integrate SunBird Calendar with Thunderbird calendar. Sunbird is in turn synced with google calendar. Works flawlessly.
• Minimize to Tray: I like to see my email client in tray rather than in task bar, as it's open 24x7.
• mozpod: To sync my contacts to my i-pod when I connect my i-pod to laptop.
• Provider for Google Calendar: To integrate google calendar with Thunderbird's Lightning extension.
• SamePlace: IM add on for Thunderbird. Lets me go online on my personal gtalk account as well as thoughtwork's gtalk account. Increases my productivity; as I am saved from multiple windows.
• xmmp4moz: Req. for SamePlace to integrate with thunderbird.

I must say, that to setup filters and other stuff I do visit my gmail inbox now and then; but apart from that thunderbird has been amazing and I have really gotten used to it in last few days.

Windows 6.5 on HTC Touch (Elf)

I have been meaning to put some info somewhere about installing Windows Mobile 6.5 on HTC Touch (Elf). I did it few days back and results have been splendid for me. Works like a charms and I thoroughly enjoy the experience.

Although I must mention clearly; I am not expert and I am reading and learning too. This post provides only a outline of step by step process that I underwent to install it successfully. But it by no means in warrantable or guranteed. :)

To note; I chose ONYX Windows Rom; which includes several other apps pre-installed. Following are the things you'll need.

ONYX 5 - At the bottom of the screen we have few releases. Choose the latest one.

ROM Backup - Rom Backup software, which will help you revert back to old version if new install is a failure. It's critical, that you maintain a backup; as it may save a lot of trobile to you.

CID/Device Info - CID and Device info will be needed if your cellphone bricks

Hard-Spl Bootloader - Bootloader, req. to load new version of windows on your cellphone.

That is it! So once you have all of it present on your computer; we are all set to go. Few precautions that you must take though.

• Make sure that your computer is not liable to switch off during installation.
• Cellphone must have more than 50% battery at least.
• Cellphone should not have any screen savers, stand by modes enabled.
• Treasure link as this may help you unbrick if requiered.

To give little background about whole process; your cellphone comes with a Official Bootloader which basically installs only signed ROMs and since the ONYX Rom that we are going to burn is unwarrantable and unsigned; it would refuse to burn it. And that would be; once you have deleted everything from your cellphone. So it bricks, if that happens.

Take backup of all your data. My Preferred tool for backup is PIM Backup but of course you can use your fav. Once data has been backed up; follow the below given steps with some common sense and guidance provided on screen by various tools:

1. Figure out and save CID and Device info of your cellphone using the downloaded tool. (Mentioned above in step 3).
2. Take back up of your existing ROM. The instructions are given on the page where you download it from.
3. Install SPL Hard bootloader on your cellphone. It'll pretty much want to restart itself. You may be req. to try several times to ensure it is done successfully. If this step fails and you try to burn ONYX rom; your cellphone may brick.

Finally you are ready to burn the Windows 6.5 on your cellphone.

Once you are through; you can set up your screen and settings. PIM Backup comes preinstalled to reload all the data. And if you were as lucky as me; in as less as 45 minutes you will be done.

For more help; contact XDA developers forum; they have all your answers and tips/tricks there. Also for a more detailed process follow this link.

Hope it helped! So long.