I think it's a law that any protocol or technology with 'simple' in the name invariably isn't.
It'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...)
SOAP: The 'S' stands for simple (not really)
51–60 of 92 posts
Re: SOAP: The 'S' stands for simple (not really)
#52Re: SOAP: The 'S' stands for simple (not really)
#53I 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:…
From which language, out of curiosity?
Re: SOAP: The 'S' stands for simple (not really)
#54I think it's a law that any protocol or technology with 'simple' in the name invariably isn't.
It'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...)
Re: SOAP: The 'S' stands for simple (not really)
#55Must 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…
I'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?
Think like this, you need to add the compulsory field of PO Number to your invoice table.
It wasn't compulsory before.
How do you not break everything?
It's impossible.
Or, even worse;
Projects can now have multiple categories. You change your code so all old requests still work, but suddenly half your systems give users the flexibility to add multiple categories and half don't.
Why's that worse? Because you suddenly have people creating projects in one system that only allows one category and then logging into another to add the extra categories because IT doesn't actually have to fix it. Total user nightmare.
And to top it all off all, and this is the actual killer, developers are having to use your never quite finished system which throws weird errors that people can't google like 'unable to add project', instead of 'violation of Foreign Key Constraint, FK_Project_User, on table Project' which tells them exactly the error.
Use standard DB access because there's a wealth of help out there, your inhouse system can't compare unless you're a big company.
Basically you've been asked to fix one of the fundamental problems of why enterprise programming is hard.
Re: SOAP: The 'S' stands for simple (not really)
#56Must 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…
I'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?
Re: SOAP: The 'S' stands for simple (not really)
#57Re: SOAP: The 'S' stands for simple (not really)
#58This 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 reques…
Re: SOAP: The 'S' stands for simple (not really)
#59Re: SOAP: The 'S' stands for simple (not really)
#60We 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.
I'm no fan of SOAP, but as a C# guy I'm curious to know what took so long?