This is a more theoretical question. I am about to build a little server in here and want to create an API for it. I am deciding what is better and already ruled out SOAP since
REST vs RPC implementations like XML-RPC is a false dichotomy. You can implement a RESTful interface using XML-RPC (although you probably wouldn't want to). That said, there are a bunch of reasons why you would want to expose resources in a RESTful way using vanilla HTTP instead of rolling your own RPC interface using a technology like XML-RPC:
See this blog post for more info.
XML-RPC is patent encumbered. You may find that you're one day asked to pay a royalty for its use. As far as I can tell, REST is not.
XML-RPC requests are opaque to security infrastructure. Whereas an HTTP aware firewall could be configured to allow REST calls to read data but not to update or delete it.
The other advantages of REST apply more to dealing with large data-sets.
REST is much lighter on the wire (particularly when using JSON rather than XML).
XML-RPC ignores HTTP semantics. All XML-RPC calls are HTTP POSTs. This has a number of implications. Including that
The XML-RPC client must load the entire response into memory so that can be presented as a return value where it is simple for a REST client to process the stream as it arrives. This means that its quite ok for a REST call to respond with any number of records where an XML-RPC API should limit the size of the response.