The nicest thing that I can say about XML-RPC is that I almost forgot I was using it on one of my projects. That never happens with soap or rest - with the former, you're always running into compatibility issues, and with the latter, you're always thinking about how to do things restfully.
"What's missing in REST, btw, is a standard method of serializing structs, lists and scalar types."
What benefit would this provide? I assume he's talking about this:
"We're all writing code, again and again, every time we support a new interface that could be written once and then baked into the kernels of our languages, and then our operating systems."
But I've never had to write new code just to parse the data from a REST API. You can usually request JSON, and there are plenty of libraries out there for that already. No new code required.
I think his problem is that he programs in Frontier and he hasn't built any support for JSON.
Library support is a rough spot when you write your own programming language, develop in it exclusively, and happen to be one of the only people in the world developing in it. He created his own XML spec for XML-RPC and wants everyone to use that instead of JSON.
I'm not sure what his point is given that the request/response format of the data normally provides the serialisation. RESTful services in that respect are no different to RPC ones.
HTTP allows you to specify the return format right in the headers of the response, so that's a clue that a REST ought not to standardize it.
About 95% of the services I use (or write) just send the equivalent of key-value pairs back to the user. JSON is the best choice here. However, for other services, the best choice is to send back HTML fragments, XML, executable Javascript, or even image and graphics formats.
The one thing I would like to see standardized is error handling. Too many service throw back 200 OK and then, in some custom way in the body of the response, tell you there was an error. This is like snatching defeat from the jaws of victory.
However, neither is it really obvious how to return the right HTTP error status. If someone asks your web service for a map centered at 2000 longitude, -1000 latitude, what do you say? 404, no such map found? or do you say 409 Conflict, even though that was really designed for PUT mid-air collisions? There ought to be statuses that more clearly map to common REST service problems, like "request parameter out of bounds". A common return format to represent such errors would be great, too.
If you're building a web service for public consumption, you want random, interested developers to pick it up easily.
SOAP has a clear advantage over XML-RPC here: blub programmers have probably heard of it, and it will be supported out of the box in their language and IDE.
> What's missing in REST, btw, is a standard method of serializing structs, lists and scalar types.
Just use JSON. Apart from being more compact, readable and parseable, it has the added bonus of being a data format, not a method-call-on-the-wire format.
