So, a little late night googling and it turns out that there is somewhat of a schism in the web services world. Now, without too much history
I am kindof
a services nut
! However, I do not know how I missed this fight
on the WSDL
acronym soup debate. As it turns out often enterprise-y tools do an amazing job at creating compatible (and even usable) web services endpoints, often in the form of SOAP with WSDL's describing the endpoint. A little investigation here reveals though just how hard it is to integrate a REST-ful endpoint to these service (often the value add of the extensible schema and type definitions quickly negates the simplicity of the REST). IMO this really leaves people in two camps - those with the automated *tools* to read the service endpoints (and quickly gain traction on interacting with the objects) and the simplicity of the REST interfaces that have very little overhead since they exploit the existing underlying architecture. I am not going to go into a tizzy here on why this seems really stupid (note to self - I should really write up some thoughts on this...)... because through this research I have stumbled onto a nifty google project: REST API code-gen
(in all its computer science-y acronym laden goodness) - this is really cool (short description here
Bam - Magic!
Woohoo - bringing robots to simple web services interfaces - I feel the future coming (unless its already dead)!