why XML-RPC and why not plain HTTP calls? where does SOAP & REST fit in?

This is good question asked by client when we proposed XML-RPC over well (internally) debated SOAP or REST kind of service invocation. Here is why I prefer XML-RPC over sending name-value pair as in vanilla HTML POST method,

1. XML-RPC takes structured data so it has all advantages that a structured data can have, like representing hierarchy & data element presense..etc. So that semantics can be controlled, preferbly through a schema.
2. Its standard way - the data I sent is understood in same way in other end.

The second learning came from an XML-RPC based project where we needed to work with large chunks of binary data. Base64 just won’t cut it when you have to transport 1-100 megabyte entities mixed with metadata records (and other structured data). We solved this by letting an XML-RPC service return dynamically generated URLs, which the client used to fetch the resulting data via HTTP. So for the first call we used XML-RPC and for second we used via HTTP.
When come to SOAP, XML-RPC is much lighter version of SOAP.
SOAP tries to pick up where XML-RPC left off by implementing user defined data types, the ability to specify the recipient, message specific processing control, and other features.

When comes to REST, I would say its a style of exposing a service - does not define any standard format for the way the data is being exchanged (could be JSON, YAML 1.0, YAML 2.0, arbitrary XML format, etc). If I see that required operation is a resource based then I would prefer RESTful call with XML data (well you have JSON, why XML when we use REST - isn;t it?). If XML presentation of data is unaviodable then go with either SOAP/XML-RPC for standard sake (interacting with 3rd party) and REST (with arbitary XML format) if it is a internal stuff.

See this post for more specific details.