3 ms·
>So, I don't get the hate for SOAP/WSDL. AFAIK one of the sources of hatred for SOAP is people building the message bodies by hand using browser JS instead of
by Arnavion 9y ago
>So, I don't get the hate for SOAP/WSDL.
AFAIK one of the sources of hatred for SOAP is people building the message bodies by hand using browser JS instead of using a code generator (one might not have existed for browser JS at that time). Not only was it complicated by being XML, but SOAP bodies are especially verbose XML.
- dreamfactored 9y agolack of cacheability is the main issue I've heard
- jbergstroem 9y agoIt's usually extra hostile for things like caching. I've (on multiple occasions) seen one URI endpoint, http posts and method as a separate header. Pretty much as far away from a sane caching best practice as you can go. Also; a lot of these older web services doesn't support deflate, gzip (accept-encoding, vary, ..) so your average responses are 500kb and up. :'( In a recent project, a client saturated their wire as a result of just this.
- ivanhoe 9y agoMy main frustration with soap services is that when it works it's great, but when something is wrong and you don't control the server side it's really frustrating to figure out what's wrong. Too often wsdl descriptions for 3rd party apis are desperately out of date, and debugging api call by looking at xml with auto-generated type definitions is hell. SOAP is just not human-friendly enough, it's too complex. In the end the most popular formats always end up being the ones that are easiest for humans to process & debug: plain text commands in telnet/pop3/smpt, html, json, restful calls, etc.