If you were expecting an exciting little post on goings on with myself you can stop reading now. This will bore you to death if you all you got from the title of this post was about cleaning and sleeping or various manifestations of both.

What this post is about is the increased inclinations of web applications towards Service Based architectures. Breaking this down -  all I mean to say is that web development has gone through several phases.

First was writing little static HTML pages that gave you the most basic information you would expect from a website and that was all you got.

The next phase was actually making the pages do intelligent things by responding to varied events a user would put a website through. Things like injecting some javascript to make the client side of the website more intelligent. Or having little islands (or indeed full blown) of server-side scripts to go back to the server to do some more processing before giving the user more information.

The next was pre-empting the users requests by actually doing things before the user requested them. Things like saving sessions, cookies and so on so as to use them for later requests to provide more personalised experience.

Now enter service oriented web development. We now have servers sitting somewhere in some cloud space doing mostly singular functions and being very good at doing those functions. A server might be only responsible for dishing out images, and or media content. Another might be responsible for user authentication, and another might just act as proxies and so on. This changes the way we develop web applications.

Now I have written only a few papers on Service oriented architecture, and a dissertation on how to test SOAP-Based web services. And i probably might be able to give you several reasons why we should use SOAP-Based web services and such. I have however recently had reasons to write a facebook application and I have had to use some pretty nifty REST methods integrating with the platform. I can say this that it was a lot quicker and arguably easier to put the application together because it was less stringent in enforcing schemas, and do on and so forth. All I had to do was write a few scripts in my favourite Server side scripting language PHP – and I was off. I was a statistic along with the thousands who have written applications for the facebook platform.

I can however say that for enterprise situations, where the company can actually afford their own servers and employ people to write and deploy java and C++ applications, SOAP makes a lot of sense. It has the structure and the “auditability” that enterprises so frequently desire. I has the ability to dynamically enforce things like Service Level Agreements and so on. I never in my experience with REST-Based web services have to deal with things like that. Security can be anally enforced with SOAP and so on.

So here’s my conclusion. I enjoy PHP, at some point it made me a lot of money and still does sometimes. I enjoy seeing immediate results integrating with other services and so on. It can be argued also that you can get these little pleasures from RUBY, Python, PERL and so on. If you follow this you might see a pattern emerging here. REST is best when you are doing jobs for scripted languages and that sort of thing.

If however one of the must have applications on your workstation happens to be Eclipse or Netbeans or Anjuta, you write a lot of compiled code those that need to run in sandboxes and you know what Tomcat and Jakarta is then SOAP I suppose is the best way to go. I remember trying to set up a tomcat server on a linux server at home and the things I had to go through those things are not what you want to go through when you want to write a quick facebook application. I suppose where this is going is that both SOAP and REST are ideal it just depends on what your services is for and where it is going. It’s a bit like that age old argument of which programming language is better… the answer lies intrinsically with the developer. And of course comments are welcome