11–20 of 92 posts
Of course, since that times I've alway advised against web services and so far I've succeeded in avoiding them.
I think it's a law that any protocol or technology with 'simple' in the name invariably isn't.
"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)
We 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 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:…