Monday, November 01, 2004

Apparently I built REST Web Services in 1999...

I do like it when an idea that has been around for a while gets a definition. A recent good example would be Podcasting, where enclosures for RSS had been defined for quite a while and yet not until the perfect application for these came along did it gain a definition and therefore wider recognition.

Being slightly obsessed with Web Services I have of course taken an interest in the SOAP V's REST debate. For a while I didn't pay attention, but as REST got more and more coverage I thought I had better take an interest in this "alternative". The following is the accepted definition of REST from Roy Fielding

"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use."

Therefore, in the simplest explanation, REST Web Services are those where the request is contained entirely in the URL and the information is returned as XML.

REST advantages

Obviously REST Web Services have their advantages, mostly they are all about being easy to use. The learning curve for a new REST Web Service is very shallow, being very closely aligned with the founding block of Web technologies HTML over HTTP. In fact the only difference is that a REST Web Service will return you XML instead of HTML, this is because HTML over HTTP is in fact a REST system.

The definitions for REST Web Services can be as simple as one or more URLs and XML Schema defining the return information.

Finally REST Web Services are very simple because they do not require complex APIs or frameworks for access.

Note: Technically SOAP Web Services do not require APIs or frameworks for access, however they are a hell of a lot more complex if you don't.

Having finally understood what REST Web Services are all about there seemed to be something familiar about them, but I just couldn't put my finger on it...Till now.

So 1999 then?

Ah yes, returning to the title of this post. Recently my ex girlfriend, who I was seeing while finishing my Computing Science degree, was clearing out her MyYahoo! Briefcase and came across what would appear to have been the only surviving and complete copy of my final year project. She very kindly e-mailed it on to me.

Well this was a blast from the past. I hadn't thought about this in a very long time, and it turns out the thoughts I had were wrong. You see I was lucky enough to be in gainful employment about a week after my last exam, and so I didn't really take much interest in my results or think about university at all for a good long time. Going so quickly into the real world of programming was a shock to the system to say the least, so I began to assume that everything that I had done before was laughable.

Taking this into account you can begin to imagine my surprise when reading my project report to learn that I had in fact built REST Web Services for it. Of course I didn't know this at the time because I had never heard of the terms REST or Web Services.

Web PMT!

The idea for my final year project came to me while in Munich on a years work placement. I spent a large part of that year building an online issue reporting tool in Perl. Before then I had done my best to avoid programming, I wanted to be a support engineer (I know, what was I thinking!). However, building this tool, sometime in '98 and '99, I really began to find my calling, which was web based applications. I could see how cool this work could be. I taught myself ASP with the now defunct ZD University (Ziff Davies subscription online learning site).

The issue reporting tool was very text heavy, typical Perl app, but I began putting charts into it, using the age old trick of stretching 1 pixel images to the correct proportions. This got me thinking about using the web to build online visualisation tools, and the most familiar to me at the time were project management tools. Hence my Web Project Management Tool was born. Please ignore the stupid acronym, I was being a "kooky" student.

This concept of an online project management tool developed further in my last few months in Munich, there were several problems that I needed to solve before moving forward. The first of these was to turn this idea into something my university would accept as a project.

"Data Visualisation and the Web"

In the end that was my title, the project was slanted towards being research into how new technologies could enable data visualisation and manipulation to be pushed down into the browser.

While I had my project, the goal and the title, I still did not know how I was going to fulfill this. All I did know was that stretching 1 pixel images was not going to be enough, so I began hunting around for a better solution.

Eventually I stumbled upon Vector Markup Language (VML), Microsoft's precursor to the Scalable Vector Graphics (SVG) standard. You should remember that I was a very inexperienced programmer at this point, so I had no idea what I was getting myself into. I was not fully equipped to evaluate the suitability of a technology, if I was I probably would not have gone down this route.

Data down the pipe

My last problem was to work out a way to send data to the browser independently of the normal HTML request, I wanted the visual layout information and the data to be separated so that the client did all the hard work. One slant to my project was to show a solution that would be good for companies with very low spec server systems by only having them deliver information and not perform much processing.

I had selected VML as my visualisation technology, not really knowing anything about it. The first stage of my education in VML was to understand this XML thing that people kept talking about. It took me a few weeks to finally get what all this was about and that VML was expressed in XML and what that meant. I had the idea that I could perhaps encode the application data as XML, but all the examples I had seen had used XML from static files however I needed to feed dynamic data to the client.

It may sound strange now, but you must remember that this was all very new to me. So I tried a little experiment to see if I could use an ASP page to generate an XML document on the fly rather than have to save it as a static file. I was amazed and overjoyed when this worked. Technically I had created my first REST Web Service.

The final year project

The project itself progressed slowly, there were many teething problems, mostly to do with strange behavior from VML. I didn't manage to do as much as I had hoped. I had really wanted to get two different charting techniques implemented (GANTT and PERT) and show how the visualisation could be changed without reloading any data.

Still, I did manage to create an interactive GANTT chart which could be refreshed with only a data load rather than a complete page load in the browser.

GANTT chart with sub-tasks rolled up.

GANTT chart with sub-tasks exposed.

Should I be proud?

This trip down memory lane has been a strange experience for me, I am left with some questions. Looking back on this should I be proud of what I achieved in the context of the time? The title of this post says that I created REST Web Services in 1999, but I have to admit that I didn't really know what I was doing so perhaps it was random chance that gave me this opportunity.

I have a strange belief in fate, so coincidences don't bother me as much as other people. Because of this I am not so freaked out that the company I ended up working for has been a heavy user and supporter of XML technologies. Barely a day goes by when I am not dealing with SOAP, RSS, RDF or WebDAV documents. I do understand that I was lucky my choices back in 1999 prepared me for all of this.

So there you are, the tale of how I managed to stumble across something new whose time had not yet come.

Note: If Rob Kinmond, my final year project supervisor from Staffordshire University, should ever happen to read this, please get in touch, I would love to catch up, to find out if you did run that course on XML the year after.


Anonymous said...

You're not alone in this situation.

SOAP webservices are heavy weight compared to REST, which are generally lightweight from most perspectives ( processing, bandwidth, learning curve, etc ).

I think SOAP is really CORBA in sheeps clothing, except now its even more bandwidth intensive.


Matt Large said...

It's true that SOAP Services are much more complex than REST, as I pointed out in the article, but that isn't always a bad thing. I think that the SOAP V's REST debate is actually a bit of a silly thing. SOAP and REST can co-exist for a long time to come.

Until the toolsets and frameworks for SOAP become as easy to use as REST is, REST will continue to be a widely used technology. I don't think you will be able to stop people from taking the easier route, especially when it just works.

However, if the toolsets and frameworks do become as easy to use, or near enough, then I think we will see a massive shift over to SOAP. The layering of the WS-* stack will give developers and companies access to features they need such as security. While these features could be built into the REST model I think it would be a shame if people focused on making REST a competitor to SOAP rather then trying to make SOAP as easy to use as REST.