The arguments about the simplicity of solutions using XML-RPC or REST are easy to understand and hard to argue with.
I have often also heard arguments that the increased overhead of SOAP may significantly impact used bandwidth and possibly even latency. I would like to see the results of a test that quantifies the impact. Any one know a good source for such information?
REST as a protocol does not define any form of message envelope, while SOAP does have this standard.
Therefor, its somewhat simplistic to try and compare the two, they are apples to oranges.
That said, a SOAP envelope (minus the data) is only a few k, so there shouldn't be any noticeable difference in speed provided you are retrieving a serialized object via both SOAP and REST.
I don't know of any answer to the benchmarking question, however, what I do know about the SOAP format is yes, it does have overhead, but that overhead does not increase per request: if you have one element sent to the web service, you have overhead + one element construction, and if you have 1000 elements sent to the web service, you have overhead + 1000 element construction. The overhead occurs as the XML request is formatted for the particular operation, but every individual argument element in the request is formatted the same.
If you stick to repeatable, short bursts of data (say, 500 elements), the speed should be acceptible.
The main impact in speed of SOAP vs. REST has not to do with wire speed, but with cachability. REST suggests using the web's semantics instead of trying to tunnel over it via XML, so RESTful web services are generally designed to correctly use cache headers, so they work well with the web's standard infrastructure like caching proxies and even local browser caches. Also, using the web's semantics means that things like ETags and automatic zip compression are well understood ways to increase efficiency.
If you're getting a lot of INFORMATION(get* type of calls) based SOAP operations, currently there is no way you can cache them. But if you were to implement these same operations using REST, there is a possibility that the data(depends on your business context) can be cached, as mentioned above. Because SOAP uses POST for its operations, it cannot cache the information at the server side.
SOAP and any other protocol which uses XML generally bloats your messages quite a bit - this may or may not be a problem depending on the context.
Something like JSON would be more compact and maybe faster to serialise / deserialise - but don't use it exclusively for that reason. Do whatever you feel makes sense at the time and change it if it's a problem.
Anything which uses HTTP typically (Unless it's reusing a HTTP 1.1 keepalive connection, which many implementations do not) starts up a new TCP connection for each request; this is quite bad, especially over high latency links. HTTPS is much worse. If you have a lot of short requests from one sender to one receiver, think about how you can take this overhead out.
Using HTTP for any kind of RPC (whether SOAP or something else) is always going to incur that overhead. Other RPC protocols generally allow you to keep a connection open.
SOAP is definitely slower. Payloads are significantly larger which are slower to assemble, transport, parse, validate and process.