Yes, SOAP is not always the right solution. It adds extra overhead, which is the price you pay for having the tools validate and map the message to objects automatically for you. It's your call weather that's worth it or not.
In many applications (mostly enterprise), the extra overhead is well worth it because of the time it saves the developers. With .NET for example, you simply add the tag "[webmethod]" before the declaration of your method, and it becomes available over the Web. And if you're building the client, you simply point your tool to the URL of the service, and it immediately pulls the declaration of all methods along with their documentation if available, and also provides autocomplete and compile time validation on those remote methods. So, most developers don't even know about SOAP and never see a SOAP message. It's all done behind the scenes. If you're using a tool that doesn't have good support for it, though, then you're going to have a hard time with it.
and get back a file consisting of "52" or something similarly simple.
Currently I have to get a 1k+ file and create a parser for it. I can't even find a really simple format that would allow me to use prebuilt XML parsers. If anyone knows of a dead simple API for temperature, precipitation, etc., I will upmod you at least once.
Indeed, my experience of SOAP seems to be data transfer overheads often totalling several hundred percent of the data transferred. This always seems to me to be wrong on principle.
I don't think I've ever seen an instance of SOAP used appropriately, and I'm finding it hard to think of even a theoretical example where it would be a good idea. Maybe I'm not the target audience, but it seems to me the code, object size and data transmission overheads are almost never made up by any advantage SOAP offers. I think I'd consider ASN.1's XML encoding before I ever considered sending a SOAP message somewhere. At least then you could translate it to DER for efficiency.
Comments
allow me to put it this way: 1k of text to get a 2 or 3 digit temperature from a weather service.
Yes, SOAP is not always the right solution. It adds extra overhead, which is the price you pay for having the tools validate and map the message to objects automatically for you. It's your call weather that's worth it or not.
In many applications (mostly enterprise), the extra overhead is well worth it because of the time it saves the developers. With .NET for example, you simply add the tag "[webmethod]" before the declaration of your method, and it becomes available over the Web. And if you're building the client, you simply point your tool to the URL of the service, and it immediately pulls the declaration of all methods along with their documentation if available, and also provides autocomplete and compile time validation on those remote methods. So, most developers don't even know about SOAP and never see a SOAP message. It's all done behind the scenes. If you're using a tool that doesn't have good support for it, though, then you're going to have a hard time with it.
As a matter of fact I'm running into this exact problem right now. RSS, SOAP, XML, why can't I just:
wget http://weather.com/api?field=temperature&zip=02142
and get back a file consisting of "52" or something similarly simple.
Currently I have to get a 1k+ file and create a parser for it. I can't even find a really simple format that would allow me to use prebuilt XML parsers. If anyone knows of a dead simple API for temperature, precipitation, etc., I will upmod you at least once.
Okay I'm pretty lazy:
http://developer.yahoo.com/weather/
Here's some ruby snippets that I used to build http://forecaster.ws
http://pastie.org/198820
Indeed, my experience of SOAP seems to be data transfer overheads often totalling several hundred percent of the data transferred. This always seems to me to be wrong on principle.
I don't think I've ever seen an instance of SOAP used appropriately, and I'm finding it hard to think of even a theoretical example where it would be a good idea. Maybe I'm not the target audience, but it seems to me the code, object size and data transmission overheads are almost never made up by any advantage SOAP offers. I think I'd consider ASN.1's XML encoding before I ever considered sending a SOAP message somewhere. At least then you could translate it to DER for efficiency.