Leaning towards REST but.....

Living a little more in the real world these days, i.e. working at the application layer, solving customer problems I have had the chance to use Web Services (SOAP and REST) in various application senarios. From that I am leaning more towards REST style architectures because in the real world I inhabit it is unreasonable to expect all end points to have the latest technology and be able to navigate the complexities of SOAP.

The biggest problem I see with the WS-*%$#? mess is that it is quickly becoming the next CORBA and is failing one of my simple heuristics, if a single reasonalbe talented engineer cannot pick up the concepts and start being productive in a week or so then there is an issue. In this case the S has been dropped from SOAP and we just have Object Access Protocol which is another way of saying RPC and leads back to CORBA. This version is better as it not tightly locked into a synchronous RPC view of the world but the complexity still exists and is growing.

On the other hand there are things I still like about the web services stack and are missing from REST. One is the degree of formalism in defining interfaces either RPC or document style interfaces. Last week I needed to access several web services and being able to query them for their WSDL was great and made my life a lot easier. Having to go through each one and look for the documentation (we all documented everything all the time right !) would have been a major pain. This is the subject of a good article by Hugh Winkler that Mark Baker pointed to. It makes a good case for have a formal interface description for REST.

So while I lean towards REST for simplicity, the ability to talk to any end point providing they have HTTP and XML the lack of a standard machine description is a big lack - I would almost be happy with a JavaDoc or NDoc type of tool but for REST to take over the Simple part of web services I think this is required