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.
Comments
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.