Såpa är bäst på TV

Jag ska försöka att inte bara negga, men en nystartad blog kommer liksom ofta från ett inneboende behov att negga - nåt man kanske inte vill eller kan göra som 'representant' för ett företag eller ens när man skyltar med sitt eget namn. Vem vet var jag hamnar i framtiden där de tycker att teknologi X är the new black och då kan det ligga mig i fatet om jag har neggat upp X i brygga under mitt eget namn. Men, men - here goes nothing.

SOAP. Simple Object Access Protocol. Faller på första ordet som utgör "S" i dess akronym. Simple, I think not. Sällan har så många name spaces, externt deklarerade entiteter och dylikt samsats i en och samma XML-blobba som i ett ordinärt SOAP-meddelande.
Testa att skicka ett SOAP-meddelande med texten 'Hello World' till en intet ont anande mottagare och förundras sedan över hur detta meddelande kunde bli 3016 bytes långt (har inte räknat bytesen i just detta exempel, men ni förstår vad jag menar).

SOAPs styrka ligger i WSDL, dvs formatet för att beskriva ett protokoll (alltså vilka tjänster som finns i en web service och hur meddelandena är strukturerade). Det är barnsligt enkelt att definiera en web service i WSDL och generera en handler-klass som sen pratar med web-tjänsten ifråga med ett enkelt vanligt anrop med typade parametrar. Så långt allt väl.

Problemet uppstår när man försöker t ex köra igenom en rimligt strid ström av meddelanden och man inser att de informationsbärande bytesen man skickar ligger nånstans runt 5% av junket man skickar. Overhead är bara förnamnet.
Dessutom är min erfarenhet att messaging mellan system är något som är väldigt specifikt; man diskuterar ett API, kommer överens om format och dylikt och utvecklar det hela. Vid förändringar så måste självklart båda sidor byggas om. Behovet av att ha referenser till XML schemas för validering och namespaces för att undvika krockar måste i rimlighetens namn höra till de extrema undantagen.
Detta suger bandbredd och CPU till den milda grad att det i princip är helt oanvändbart, ja rent ut sagt oansvarigt, att använda SOAP i de allra flesta fall.

Ett Simple Object Access Protocol (över HTTP) bör tillåta:

• GET-baserade anrop (skit i indempotensen). För ostrukturerad data t ex ett id, kör webtjänsten med get och en url-parameter. Går dessutom utomordentligt att provköra i browsern
• POST-baserade anrop för mer strukturerad data (t ex resultatet av ett inmatat formulär)
• Lean and mean XML-representation av ett objekt:


<user>
<username>leif</username>
<mailaddress>leif@leif.com</mailaddress>
</user>




Ett dylikt webservice-ramverk langar man ihop på en eftermiddag (nåja) - satisfaction guaranteed!