It gives you a unified means to specify functions, along with parameters and their types, and gives errors when the requests don't match the definition. With a REST implementation you roll yourself, you'd just have to re-implement this stuff, wouldn't you? Or what am I missing?

I see things in the reverse: HTTP and REST give you a way to make requests, specify parameters, indicate errors, authenticate, etc. XML-RPC ignores all of that and makes you re-implement all of those things.

Tricks like appending ".jpg" to the url seem a little hack-ish to me. That feels like a parameter. Now what if there are two parameters, how do I know which comes first if someone else wrote it who doesn't use the same style as I do?

Those are meant to resemble file extensions, but they can be thought of as parameters.

If I'm querying for an employee, is it clear that I should use employee/110.jpg and not employee.jpg/110 or employee/110/jpg or employee/110/query/jpg, or somethere else?

It's not standardized, just like XML-RPC isn't. Either way you can read the documentation for your service and it'll tell you.

Alternatively, in REST everything has a URI. This has two interesting properties:

1. You can always access a resource by its unique URI: http://example/employees/110.jpg

2. As seen on the WWW: hypermedia links. If you request /employees.json, for instance, I can provide a structure like:

  {name: "John Employee", related: { image: "http://example/employees/110.jpg", performance_review: "http://example/employees/110/review" } }

Which means that with your response you can easily request those URIs and get the resources. Those URIs should never change (as mentioned), but HTTP provides for redirection if they do. XML-RPC does not provide for this at all.

(edited for formatting)