ROA as an architecture is tied to HTTP and URI (this is not a value judgment — ROA is important because it clarifies the issue of how to make a truly RESTful system on the Web). REST as a style can be adapted to many different settings. I think everything I was saying about the uniform interface, hypermedia, and layered systems applies to the style as a whole.

I was sloppy in giving RPC the status of a style, but we don’t have enough information to ascribe any particular style to the example above. The key thing we’re missing (and I see this a lot in RPC examples) is how does application and resource state change? If the resource is completely stateless and algorithmic, then we’re probably looking at a Client-Stateless-Server, which may yet be RESTful (but not a ROA, given the the URI format).

The key thing is that if we go a step further and say it’s not only stateless, but RESTful, a lot of other things (cacheability, layering, etc.) come along for free.

XML-RPC is a protocol built in an RPC style, and it’s the protocol that’s responsible for the serialization, API, and library support that you’re pointing to. A similar RESTful system could use XML, YAML, JSON, etc as serialization methods (and as you rightly point out, these serialization formats aren’t the issue) as long as it abides by a couple of architectural constraints.

Those are (roughly):
1) Addressability of application resources (e.g. URIs for data)
2) An explicit, simple, and consistent interface (e.g. the familiar HTTP “verbs”) that dictate how the server state changes (i.e. when to save/delete something or when we can reuse/cache a result and which operations will have the same results when reapplied in case the first try failed).
3) Hypermedia as the mechanism for client change. You indicate the “next steps” for the client.

And by no means is a RESTful architecture limited to HTTP, it just happens to be the most widely deployed protocol of the style.

If we’re talking about architectural styles, RPC vs. REST is a better comparison — indeed, it’s one that Fielding devotes a lot of time to in his thesis. Some simple weaknesses of RPC apparent right off the bat are that we loose the ability to cache results in the client, intermediaries, and server because the protocol (as an implementation of an architectural style) doesn’t make it explicit if we’re just supposed return a value, or if we’re supposed to change something in the application.

I find it interesting that “cross-language, typeful serialization of data” is praised, but its all tied towards XML.

Personally I think we should all untie the data behind software, from the language, solution, paradigm etc…

And then, if possible, save the data in a format that gives us the most advantages while having fewest disadvantages. For my use case, I can not really be friends with XML either because it is not human-readable enough, or because it is a rather slow-ish solution. (The human-readable aspect is what i worry more though, else i think we should stop caring anyway and just use a real database format, without needing to have “human-readable” aspects in mind)

For me, REST always was much more in focus of human people, with sane action-based URL mapping.