8 ms·
SOAP: The 'S' stands for simple (not really)
- grnknight 16y agoWow. This sums up my entire exposure to SOAP over the last few months. Thanks for the humorous, yet factual exchange of information!
- lkrubner 16y agoThe original article is here: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-... I am glad to see it get more attention. It is a classic and it is really about more than SOAP. It is about the way technologies get hyped and over-sold and over-promised, and then made unusably complicated. SOAP is just the example.
- raganwald 16y agoIt is about the way technologies get hyped and over-sold and over-promised, and then made unusably complicated. In the excellent book "Antipatterns," I recall that this is called a "Wolf Ticket:" Wolf Ticket is a product that claims openness and conformance to standards that have no enforceable meaning. The products are delivered with proprietary interfaces that may vary significantly from the published standard. http://sourcemaking.com/antipatterns/wolf-ticket http://sourcemaking.com/antipatterns/wolf-ticket Wolf tickets are sold as safe choices because of their interoperability, but of course once you have anything non-trivial built upon them, you discover that the interoperability doesn't actually work and you are left locked into your vendor.
- dminor 16y agoI think it's a law that any protocol or technology with 'simple' in the name invariably isn't.
- JoachimSchipper 16y agoSMTP is really quite simple. Of course, the array of hacks that is a modern mail infrastructure isn't - from SPF via Bayesian spam filtering to MIME - but the protocol itself is, really, quite simple.
- fanf2 16y agoHowever it has quite a lot of complication in the encrusted extensions - http://fanf.livejournal.com/64533.html http://fanf.livejournal.com/64533.html
- viraptor 16y agoSo true... even worse for stuff that is named "SIMPLE" in capital letters. SIMPLE -> "Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions". And no, it's not. It's based on ~100 of very long RFCs that make up SIP itself. Also it includes XML... and namespaces... and schemas... and some custom phone-specific values to make it less compatible with anything and more (and references HTTP and privileges model).
- cperciva 16y agoIt's also a law that any field with the name 'science' in it isn't a science. (Health science, social science, military science, earth science, computer science...)
- adw 16y agoWhich is why my the department I'm an alumnus of called it Earth Science_s_ - http://www.esc.cam.ac.uk/ http://www.esc.cam.ac.uk/ - which is fine: it's a coalition of mineralogy, mineral physics, petrology, paeleontology, geophysics and rheology...
- ranit 16y agoyou missed ... christian science :-)
- lsd5you 16y agoAnd any country with democratic or people's in it's name, is not democratic or belonging to the people (Democratic Republic of North Korea, of Congo, PRC ... )
- kree10 16y agoI once worked at a company that had a platform named "Occam". While I was learning the system, I asked someone who had been there for a long time if they had chosen that name ironically. He didn't think it was funny.
- chrisbroadfoot 16y agoMy worst memory of SOAP was dealing with an attachments API that required each byte in a byte array to be wrapped in an XML element. You ended up transferring ~10x the size of the file. I suppose gzip would have helped somewhat.
- ZoFreX 16y agoMy worst memory of SOAP is using it. Experienced it for the first time ever a couple of weeks ago (all I've used before now is ad-hoc JSON or XML apis, mostly JSON) and (knocks on wood) never, ever again. The article touches on a few of the things I really didn't like about it, the main one being the expectation that you will use tooling to generate code rather than the contract first, and that every time I hit a hurdle and switched to a different library, I had to start over.
- deleted 16y ago[deleted]
- GFischer 16y agoThat is awful, and I'd never defend that implementation, but you can compress http (sorry if by "gzip would have helped" you meant that) http://en.wikipedia.org/wiki/HTTP_compression http://en.wikipedia.org/wiki/HTTP_compression
- bockris 16y agoReminds me of the "Why I hate frameworks" essay by Benji Smith. http://benjismith.net/index.php/2005/09/30/hate-frameworks/ http://benjismith.net/index.php/2005/09/30/hate-frameworks/
- otoburb 16y agoSome previously implemented projects implemented a SOAP prepaid account balance billing interface that runs in production today. Nobody is willing to touch the interface for modifications because every developer tasked to review proposed changes complain that it's way too brittle and prone to complexity. This article is bittersweet because it sums up everybody's feelings pre- and post- implementation.
- jan_g 16y agoMust be ~5 years since I last used SOAP. Needless to say I hated the stuff. Complex to build, complex to use (interoperability between different stacks - java/.net/... - was like 'cross your fingers and hope for the best'), complex to debug and walk through tcpdump network packets. It's complex in every way but the name. Of course, since that times I've alway advised against web services and so far I've succeeded in avoiding them.
- wizard_2 16y agoI'm being asked to create webservices so other developers don't do direct database access and their stuff wont break when things change. How do you manage that?
- didip 16y agoIf you use MySQL, slap this bad-boy(http://code.nytimes.com/projects/dbslayer http://code.nytimes.com/projects/dbslayer) between the app and the database. The payload is JSON over HTTP.
- dansingerman 16y agoDesigning an API is a skill in itself, but I think rule 1 is "Don't use SOAP" JSON over REST seems to be flavour of the month FWIW.
- roc 16y ago"Flavour of the month" might be a bit harsh. It certainly is popular these days, so it's not wholly inappropriate. But it's worth noting JSON/REST is popular with, and largely because of, people who've learned the painful lessons of earlier messes like SOAP. It's not (just) a hot new thing used by new faces who've never really known any other way.
- dansingerman 16y agoI actually didn't mean to disparage JSON over REST in any way. In fact I really like it. I only qualified the statement as technologies change quickly (only 12 months age we would probably have been talking about XML over REST) and things will no doubt change again.
- nervechannel 16y agoAs an ex-SOAP-dev... Yeah.
- erikstarck 16y agoDesign-by-committee in action...
- colinloretz 16y agoI do a lot of Salesforce.com development and the use of SOAP has been the bane of my existence. They have recently introduced a new REST API that will be going GA in the spring. "Dev: What happens if I GET the endpoint’s URL? SG: Don’t know. Using GET is undefined. Dev: Hrrm. And what happens if I move the service to a different endpoint? Do I get a 301 back? SG: No. SOAP doesn’t really use HTTP response codes. Dev: So, when you said SOAP uses HTTP, what you meant to say is SOAP tunnels over HTTP." The beauty of REST is that it is representative of how the web works. With SOAP you're almost always limited to the use of POST methods and when I go to read another developer's code, I see their own defined nouns and verbs for resources they are sending/receiving like "getUsers", "getContacts", and "createPerson". These often are ambiguous or don't match up with the actual resource they are trying to work with. Endpoints in REST are self documenting, you can read what it is that you're trying to do based on the endpoint and the HTTP verb (put, post, delete, et al)
- lanstein 16y agoFrom which language, out of curiosity?
- colinloretz 16y agoPredominantly PHP and Ruby.
- F_J_H 16y agoWould be interested in hearing more about your salesforce.com development. Can you email me at the address in my profile?
- orangecat 16y agoWe have the misfortune of dealing with a third party SOAP API at my office. My coworker did it the "correct" way, autogenerating thousands of lines of C# from the WSDL and trying to get the objects transparently serialized and deserialized. That turned out to be a multi-week effort, so finally I got fed up and spent 4 hours writing code to directly extract the values we needed from the raw XML.
- vyrotek 16y agoI'm no fan of SOAP, but as a C# guy I'm curious to know what took so long?
- silverbax88 16y agoI've got the same question. But I've written them in both Java and C#. I worked on a project recently where we had a team of Java guys who worked on a SOAP implementation for a month. They could not get it to work in any way, shape or form. It was handed to me, and three of us did it a half an hour. All custom SOAP, still worked. I just don't comprehend why this seems so hard to people on Hacker News. SOAP is just another protocol and as messy as any other.
- steveklabnik 16y ago> SOAP is just another protocol and as messy as any other. I think that's where you and most of the other people on the thread are losing it. SOAP is way messier than just good old REST. (disclaimer: I've never been forced to actually use SOAP.)
- SoftwareMaven 16y agoI have had to do both: SOAP is WAY more messy.
- orangecat 16y agoI'm not sure of the details. I vaguely recall there was a version mismatch with the provider's API, and at one point they were sending UTF-8 data when the header said UTF-16, or vice versa.
- bediger 16y agoWhy did SOAP win, and XMLRPC not win?
- dochtman 16y agoBig companies and their commercial interests.
- bediger 16y agoWhy in an earlier age, did DCE fail so miserably? It was amply backed by ginormous corporate interests.
- duncanj 16y agoOne reason is that Microsoft's implementation was compatible enough with Sun's to pass tests but not to perform much useful work. Without MS's active participation, most enterprises wouldn't benefit from interoperability.
- wiredfool 16y agoSoap was supposed to be the enterprisey safe superset of XML-RPC. From my experience back at the beginning -- XML-RPC was slightly underspecified, and would have used a bit more of a firm hand about clarification of what was legal and what wasn't. SOAP was wildly overspecified and complexified to the point that you needed an army of consultants. Which is just perfect for enterprisey stuff, since you conviently have an army of consultants that need to have something to do. IMHO, XMLRPC inhabited a middle ground that was washed away by REST and ajax/json type interfaces. It's an extra bit of complexity that's just not all that popular now, rather than a stunningly less complicated version of SOAP.
- spolsky 16y agoYep... as I remember it, XML RPC was "specified" by Dave Winer, and it was really sloppy. As I remember, there was no discussion of character encoding in the spec, and if you read the spec literally, you actually HAD to generate invalid XML documents because the spec was written by someone who did not understand that there was such a thing as character encoding and that it was important. And Winer absolutely refused to add features or to allow any kind of process by which XML-RPC could evolve into something good enough to use. Then the Microsoft people who brought you COM in all its baroque loveliness got their hands on the concept and made an industrial strength, godforsaken, complex thing called SOAP. The problem with SOAP mostly stemmed from the fact that they thought that all the work would be done by compilers and IDEs and so forth... they thought all the programmer would do is click a button and hey presto they would be able to run one object on one server and another object on a second server, and who cares what happens on the wire protocol? It's the compiler's job! But that's a terrible recipe for interoperability.
- st3fan 16y agoSOAP really just exists to keep a tools/consulting/appserver/softwarestack business alive. Pretty sad.
- Sidnicious 16y agoThis is great. My (so far, only) experience with SOAP started when my boss asking me to investigate the new version of a (very big) vendor's SOAP API. Support for the old version of the API was being dropped in a few days. It turns out that our framework has SOAP built in, so I had it suck in the WSDL and make a sample request. It was rejected with a generic error. As it turns out, our framework was generating requests that looked like this (simplified with much SOAP nonsense stripped out): <SOAP-ENV:Envelope> <Authenticate xmlns="http://bigcorp.example.com/elements/global">…</Authenticate> </SOAP-ENV:Envelope> …and the requests in the API documentation look like this: <SOAP-ENV:Envelope xmlns:bigcorp="http://bigcorp.example.com/elements/global"> <bigcorp:Authenticate>…</bigcorp:Authenticate> </SOAP-ENV:Envelope> the difference being that our framework declares a "default namespace", while their API expected a "namespace prefix". As far as I could tell from reading the spec (always a bad sign when you're using a standard that both ends support) the difference shouldn't matter. - - - I went to my boss. He showed me the old code; all the requests it needs to make are hardcoded based on the docs, and substitute XML-encoded variables in the right places. Save a few minor changes, that's the process we still use today, and it fucking works.
- dfranke 16y agoSomething's seriously messed up if, once the XML has been parsed, their code can even tell the difference between those two constructs, much less care.
- donspaulding 16y agoThis has been my exact experience wrapping several big SOAP APIs. Worse still, I've (recently!) wrapped an XML api that cares about the document-order of sibling elements. It might as well be a binary format if I have to copy your request examples and can't use a bog-standard XML parser/generator.
- aidenn0 16y agoSOAP has always seemed bizarre to me. It's something like "We think CORBA was a good idea, but they messed some stuff up, so we'll toss the entirety of CORBA and make something with a completely new set of problems while completely ignoring most of the mistakes we learned with CORBA." I'm still luke-warm at best on the whole ORB idea as-is, but even thinking from the point of view of someone who thinks object brokers are the best thing since sliced bread, I feel like the SOAP people got it very wrong.
- tomelders 16y agoI feel a bit sad for all those people who worked on SOAP. I assume most of them simply wanted to make the web better and now we all point and laugh at their efforts with the 20/20 vision that only hindsight can allow. Thanks for trying SOAP people, it was a noble effort but it's game over I'm afraid.... oh wait, I just saw on Wikipedia that these were Microsoft people. In that case, screw em. SOAP is wank! YOU'VE WASTED YOUR LIVES!!
- Ingaz 16y agoEven worse for CORBA. .. On the second thought: The same companies made SOAP right after and along with CORBA. Maybe, even the same people. Don't blame Microsoft too much: IBM, Oracle, SAP, BEA - they are all ... equally "good"
- ahupp 16y agoAt one time SOAP wasn't too bad, until it tried to solve a lot of complicated problems (via WS-*), and in the process made the simple problems complex. Contrast this with HTTP which is being used for ever-more complex problems yet is really no more complicated in the simple case than it was in 2000. This seems like an important principle in protocol design.
- pornel 16y agoIndeed. "RESTful" is basically a name for using HTTP well, and such APIs are usable for anything from bash script to Big Vendor Library™.
- RyanMcGreal 16y agoThis wonderful Socratic dialogue has articulated my professional hell over the past six months.
- motters 16y agoI never did anything using SOAP, and thought that this technology died many years ago.
- naba 16y agoSigh. this article made me a little sad. I keep wondering why the corporates who have all the money and resources keep using a technology that is just so old and has so many issues, when they have the better alternatives. My entire week was spent in just trying to get the configuration and a hello world service up and running.
- dedward 16y agoIt crosses some layer boundaries too.... having to manually edit (or I guess dynamically generate) wsdl files so that we can add a reverse proxy or load balancer in front of a webservice machine to access it several different ways in .net was definitely a pain in the butt.
- Rabidgremlin 16y agoLove it. However at least SOAP is a spec and generally works. REST is an architectural style there is no spec, just a idea! Added to that most folk also only build REST-like services. Implementing a client for REST based services often requires a bunch of (generally simple) coding which takes time and is error prone. Also pure REST is really good for building data access/CRUD services but makes it hard to build RPC type services without mangling the semantics.
- generalk 16y ago> However at least SOAP is a spec and generally works. SOAP has several versions of the spec and a bunch of vendor-specific cruft. The SOAP use-cases from this comment thread are enough indication of that. > REST is an architectural style there is no spec, just a idea! Yeah, but you use REST every day in your web browser. A lot of the times it isn't strongly RESTful, but it's still REST. For example, to view this comment thread and post your reply to someone's comment. In SOAP, if I call the getUserByID(42) method on your end, and you don't have a user with id 42, what do you do? Do you return an empty response? Do you return some kind of SOAPFault? If so, what kind? In REST, if I GET http://yourservice.com/users/42 http://yourservice.com/users/42 and you don't have user 42, I get HTTP 404. That's the only logical response. > Implementing a client for REST based services often requires a bunch of (generally simple) coding which takes time and is error prone. This is no different from SOAP, with the exception that with SOAP you have to have your requests stuffed into XML by some libraries which have read some other autogenerated XML to figure out how to stuff your requests. With REST, you can write a library (that wraps HTTP calls), or you can use curl, or (for simple GET requests) you can use your browser. Your platform might not support SOAP, but it definitely supports REST. > Also pure REST is really good for building data access/CRUD services but makes it hard to build RPC type services without mangling the semantics. This has been said multiple times but let's say it again: REST is not RPC. If you're looking to remotely call procedures on your app, REST isn't going to provide that. The only case where REST doesn't work is the case where your client demands SOAP. In any other case, REST works beautifully. Not everyone does REST right, but even when it's done suboptimally (e.g. not providing hyperlinks to related resources) it's still worlds better than SOAP.
- theBobMcCormick 16y ago
- ph33t 16y agoLet me preface this by saying I'm not particularly a microsoft basher, however this smacks of their history of interface development. Remember COM in the 90's? It was so complicated no one really knew how it worked. The only way to use it was to use a compiler that had native support for it ... MS Visual Studio and MS VB. Delphi came a long way quickly and made it work. Anyway whether intended or not, the result was you were initially tied to using a MS tool to use the technology. SOAP seems the same. Odds are if you're writing one end of it or another (client or server) somewhere the mix you're going to have a Microsoft tool. If you want to talk to the product of that Microsoft tool by far the easiest way will be to use a Microsoft tool. So despite being "open", their implementation of it ties you into some vendor-specific tools.
- mike-cardwell 16y agoEurgh. Reminds me of writing Perl code to talk to .NET SOAP services in a previous job. Never again.
- Aaronontheweb 16y agoThe only thing I like about SOAP's modern implementation is that it comes packaged with a WSDL usually - I would welcome a world where most REST APIs included a WSDL so I could just automatically stub a wrapper library.
- donspaulding 16y agoA quick note to those python devs out there who have to wrap SOAP APIs and haven't discovered it yet, https://fedorahosted.org/suds/ https://fedorahosted.org/suds/ is a very clean and pythonic SOAP client library. It's developed by a man named Jeff Ortel (on behalf of Red Hat, I believe), and it kicks the pants off of SOAPpy/ZSI/wsdl2py or whatever else you're using. You're welcome.
- mcherm 16y agoOh god... that's my life!
- yogipatel 16y agoI stopped using SOAP in the shower a month ago and have never felt cleaner. Showering is a more efficient process now: - I spend less money on resources (SOAP, lotion, etc) - I get clean faster -- SOAP used to slow me down - Using someone else's shower is easy, I just take my towel. I don't have to worry if their SOAP is compatible with me.
- ojbyrne 16y agoThe "Simple" in SOAP is seriously overtrumped by the "Simple" in SNMP.
- Jeema3000 16y agoI will now share my secret SOAP API Pro Method: Step 1: Ignore all tools which supposedly make things easier (very important) Step 2: Find the web service API documentation Step 3: Ctrl-C example XML request Step 4: Ctrl-V example XML request into program, replacing appropriate parts with program variables Step 5: Parse the response. You're on your own here... Godspeed. :)
- Groxx 16y agoThe company I work for has to digest a handful of XML and SOAP protocols. Theoretically, they all conform to spec A or B, and/or define their own subset of that spec with an XML language definition. There should be like 3 or 4 pieces of code which would handle every format they offer. Practically: ctrl-C, ctrl-V, and call them when it doesn't work. More often than not it's either A) incorrect documentation, or B) you hit a bug (yes, this means their sample-code doesn't work. It happens frequently). A good chunk of our request-data builders are simply string manipulators, because some of the APIs we call are nitpicky about the order of XML attributes in a tag. I laugh when people tell me XML works better "because it's a standard".
- iwwr 16y agoCould it be that SOAP never had a solid set of test cases? Implementing a reasonably complex API should involve passing a series of public and very specific tests.
- Confusion 16y agoIt's easy to rant, but hard to come up with a viable alternative, that encompasses the same scope. XML-schema and WSDL are mocked as an aside, but I dare you to provide me a REST alternative for those, as standardized as those. For all the horror stories, I have used Java to interact with a C# webservice without any pain, including WS-Adressing. The WSDL and XML-schema were a godsend compared to the earlier spec. Like people that think you can just replace XML with JSON: you are missing stuff.
- rue 16y agoA REST alternative for what?
- MarkMc 16y ago"I trust that the guys who wrote this have been shot." Ha ha! I must remember this put-down - it could be used in so many contexts :)