Uhm ... to put it simple, both are very abstract models ... so abstract, they naturally occur everywhere...
REST is the idea of having resources addressed with a global identifier (the URI in the case of HTTP) that are accessed in a CRUD way (using POST, GET, PUT and DELETE in the case of HTTP ... well, at least that's the idea)...
RPC is the idea where you call a procedure on a different machine, passing in some parameters, and taking a return value...
There is a nice short comparison on Wikipedia
Persevere creates a service, that allows both (in a very elegant way, admittedly) ... it is RESTful (although it does not only use HTTP-features to achieve this) and exposes an RPC interface...
In the end, you should look at what your application needs to do ... as most people, you'll probably wind up with an RPC API (be it based on XML or JSON or whatever), that includes a transport layer for a partially RESTful subsystem ... this is, because having RESTfulnes, means flexibility ... if the client can more or less freely traverse the data on the server (through a set of simple CRUD methods), it does not depend on a limited (problem-specific) set of methods exposed through the API, and you can shift logic clientwards...
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…