WebServices is a massive mess - AllegroWebAPI

Context note for non-Poland-based readers

Allegro is polish e-bay style auctioning service (actually e-bay was unable to compete with Allegro on local market). Allegro engeneers have set up a Web Service AllegroWebAPI, which is base for discussion below: http://webapi.allegro.pl/uploader.php?wsdl

First WebServices encounter

I have recently read SOAP: S stands for Simple article, and became a little worried.
Till that moment I haven't considered WebServices as Evil incarnation, the way article's author describes it. I respected that technology as is seemed so Big and Professional. One can even get a Sun's certificate for it: certyfikować.

I decided to finally take a first step towards learning WebServices and went for Allegro Web API. Downloaded Axix 1.4 (Allegro uses very old style of WSDL), generated SOAP Proxy as ant suggests (polish, see scripts only) and used it to login to allegro.

Next I have inspected the SOAP proxy code that Axis generated and, man this is scary!

• Proxy weights 1.5MB
• Code has > 8000 lines
• Coding style does not differ substantialy from C macro-cluttered garbage
• methods do not return values, instead relying on side effects on Holder objects

Now this is WRONG path. This is not object programming and this is functional programming neither. This is Big ball of mud heading straight to unmaintainable, buggy applications.
How such a mess can be so widely used?

Few days later..

API changed. Whoa, my app no longer works - I need to regenerate my SOAP proxy just to log in. There is no way to know for application that WSDL needs to be reprocessed. Unless of course application reads developer forums. Mine doesn't, I'm toast...

The moral of this story

From https://secure.wikimedia.org/wikipedia/en/wiki/REST

SOAP RPC over HTTP, on the other hand, encourages each application designer to define a new and arbitrary vocabulary of nouns and verbs (for example getUsers(), savePurchaseOrder(...)), usually overlaid onto the HTTP 'POST' verb. This disregards many of HTTP's existing capabilities such as authentication, caching and content type negotiation, and may leave the application designer re-inventing many of these features within the new vocabulary. Examples of doing so may include the addition of methods such as getNewUsersSince(Date date), savePurchaseOrder(string customerLogon, string password, ...).

UPDATE:
Please drop the SOAP - another rant about SOAP bloat.