"With the advent of networking it seemed natural to allow for the leveraging of these functions by enabling function calls to be made across the network. The act of making a function call on one machine but having the call executed on another machine is referred to as a Remote Procedure Call (RPC).

RPCs allow for the rapid development of network protocols because they enabled function based programming, something humans have repeatedly proved themselves pretty good at.

When RPCs were largely limited to local area networks with low latency things worked quite well. Because RPC calls tend to represent small chunks of functionality the performance limitation wasn't the network as much as how fast the machine could process an incoming request. Optimized RPC implementations could routinely handle thousands of requests per second so everything worked just fine.

Problems started to occur when attempting to run RPCs over high latency networks. Here the limiting factor is the network, specifically latency and this is where RPC's drawbacks began to outweigh its benefits.

Because RPCs are designed like functional programs they tend to follow the normal human way of thinking and break each problem into small, well-defined chunks. Each chunk was assigned its own function call. To perform any significant amount of work one had to call numerous function calls. Each of these function calls turned into a network round trip. On a high latency network such as the Internet these round trips were quite expensive. The result was that RPCs didn't tend to work very well across the Internet.

This is where protocols came in. Protocols are tuned for latency rather than human comprehensibility and therefore are able to achieve significantly higher performance across high latency links by aggregating many functions into a single round trip." (Yaron)

This is where REST web service mindset lies. REST encourages cross grained communication and thinking in documents instead of functions.

The downside of REST approach is that you have to parse the XML documents manually instead of using the quicky SOAP/XML-RPC calls.

Another downside is you must design your xml document  instead of throwing a buch of parameters to a [WebMethods] SOAP methods.

In REST, you stuff up all the information you think you might need in one call. Everything and the kitchen sink. Let the client to worry about shifting. So add complexity on the parsing side but you oh just have to make one call.

So this is a trade off between the speed of development compared to scalability, extensibility and elegance issue.