Martin Probst's weblog

Applied XML in RSS, SOA(P) and REST

Tuesday, March 29, 2005, 15:46 — 3 comments Edit

Lately there have been lots of debates about SOAP vs REST. To quickly summarize it: both SOAP and REST are about making ressources accessible via the web using XML. They have two different solutions for this. SOAP provides a toolkit that (in the best case) seamlessly integrates with your programming language of choice and provides the access to ressources by e.g. method calls on an object. This is done by providing a machine-readbale definition of the interface (WSDL file).

REST is about not providing a toolkit but rather defining simple APIs using HTTP GET, POST, PUT and DELETE as the commands, passing around chunks of XML. People argue that this is simpler than SOAP with all it’s toolkits (which are partially incompatible to each other etc.) and much more similar to the current architecture of the web, which is a great success after all.

Now all this stuff about Service Oriented Architectures seems to be marketing speak. But will REST really be better then SOAP? RSS feeds are an XML application which is already deployed very widely. It’s supported by many different tools in a read-only mode and by some even with a posting method.

The pro for REST is that RSS somehow works. People started providing content via HTTP GET in some rather loosley defined format, other people wrote aggregators for these ressources, and today we can read news from many different sites on our desktops easily.

The con is the effort needed to provide RSS support. Some of this comes from the “loosely defined format”. But the biggest part is from malformed XML, at least as far as I can see (blog posts by prominent RSS tool authors seem to support this). There is hardly any feed out there that really adheres the format. Additionally, there are lots of feeds out there which aren’t even XML. There is a huge amount of issues, from simple bad nesting to unescaped content, double-escaped content, bad namespaces, bad content encodings, etc. pp. And this is not even about adhering to a special schema. XML looks as if it was very easy to write and read, but in reality it’s a lot more complicated than you might think.

Now what does this mean for REST? I think it is very likely that all custom XML applications where people don’t use toolkits, but rather write angle bracktes themselves, will suffer from the mentioned problems. You might argue that this is not such a big problem as RSS reader authors seem to get along with it too. But in this case everyone who wanted to use a specific REST application would need to write some magic, ultra-liberal parsing application. She wouldn’t be able to use XML technologies like XPath, DOM, XSLT out of the box, she wouldn’t even be able to use SAX.

Apart from that, assuming people were able to at least provide valid XML. What about the API. With RSS it’s relatively easy, there is only one big GET. But what if you wanted to provide more, like GET last 5 posts? You would start inventing an API, e.g. via query strings. Nothing bad about that, but how do you document that API? As far as I have seen it, most documentation in companies is done using Word documents. Most of this documentation is either too old, barely understandable, much too short, simply wrong or a combination of these.

A decent SOAP toolkit would provide the XML serialization of objects. It would also provide a basic minimum of documentation of the API (people would at least know which functions exist). Noone really has to care about the exotic WS-* stuff, but it’s there if you need it.

REST might be good for really small, really simple applications. But if you want to start something bigger, something that might involve lots of developers, might change over time, has an API that provides more than two methods, you should really use a toolkit or it will be a mess.


RSS, REST, SOAP and SOA

Martin Probst does his best to fulfill is buzzword-quota. He shows his thoughts on Applied XML in RSS, SOA(P) and REST .

There are two responses for his article. I do not think that REST ? will suffer from the same problems as RSS ? , as it is


I agree with you on the basic XML problems, mainly encoding, that will be much more prominent if no toolkit is used and everything is done by hand. My personal opinion is that this is due to a complicated encoding mechanism used in XML with tons of variants that I never understood - reading a 100-page Unicode tutorial might help but I didn’t come so far yet…. If I’d just be able to insert plain german Umlauts like ä, ö and ü inside an XML document!

Well, I’m drifting away. What I see as the advantage of the REST approach (and the web), is that you keep everything simple - KISS™. If you really do that, you won’t get a large API with lots of methods and the problem of documentation is very small - as you already mention. The key point of REST over toolkits like SOAP is that they should be used when a manual approach is simpler and you are able to customize it to your needs. It might be a bit like it is with XML parsing/access APIs: no one likes DOM or SAX really, there exist alternatives for all programming languages that fit more to the environment and make use of the language’s features (examples are REXML for Ruby - http://www.germane-software.com/software/rexml/ - and the great DAX for Java - http://www.asciiarmor.com/blog/default/?permalink=Introducing_DAX.txt).

Well, just some thoughts, REST is actually completely new to me, just read a few articles so far.


Atom Store and the Atomverse

Dreaming of an Atom Store: A Database for the Web describes a database of structured information, Atom enabled for content publishing and retrieval, and REST for applications. See Applied XML in RSS, SOA(P) and REST.
If more timely information source...