- Standard, cross-language, typeful serialization of data
- User-defined error codes and messages
- “Boxcarring” of requests to reduce overhead
- Serialization of binary content
- Serialization of date-time values
- Standardized parameter passing
- Introspection allowing for straightforward code generation
- High-level APIs for just about every language
- No manual parsing of XML, ever
- Only three lines to call a function in Python and several other languages:
>>> import xmlrpclib
>>> s = xmlrpclib.Server(‘http://localhost/xmlrpc’)
>>> s.demo.addTwoNumbers(3, 4)
7
Not that the REST doesn’t have its benefits, but someone ought to be saying this. XML-RPC isn’t complicated like SOAP, it runs just about everywhere, and it lets you get on with your work rather than arguing about semicolons versus slashes or XML versus JSON or countless other things. Besides, when your goal is to support as many languages as possible, you want to minimize the amount of code you write for each language. As far as I’ve seen, nothing else accomplishes literally no-code binding like XML-RPC.
Hmm… I feel like you’re missing one of the major architectural advantages of REST. REST simplifies through unification of all of the data on the internet into a collection of resources. As the semantic web gains traction, this also means that all internet data is essentially machine readable. If REST gains major traction as well then that means that ideally all internet data would be machine readable and uniformly accessible.
I think that’s extremely powerful.
I’m still learning about REST and it’s implications so I don’t mean to sound like I’m talking down to you. I don’t fully grok it but it makes me feel like there’s something big about to happen with all of this. I’m really excited by REST and I don’t think I can quite put it into words yet.
-Justin
The thing is to compare a RPC architecture VS ROA (resource oriented architecture). It’s more simple (without any doubts) use xml-rpc, but a REST system is more rich and powerful (although more dificult than xml-rpc).
Pingback: A song for the lovers » If XML-RPC is really better than REST, it’s not for there reasons.
Yeah, but REST is (should be) used for things that are simple enought not to need any of these.
Isnt XML-RPC inherently tied to XML?
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.
Pingback: Sp3w » Blog Archive » Linkage 2008.03.24
That’s pretty impressive that you could add 2 numbers in only 3 lines of code. Reminds me of working with J2EE.
I think there’s crucial distinction between between XML-RPC as a protocol and RPC as an architectural style that’s not being made here.
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.
Please remember that one size does not fit all. Some problems are inherently simple and their solution should be likewise simple. Other problems are sufficiently complex that only a well thought out and rich technology will suffice. Just as stretching the limits of a simple tool is a poor choice, so is adding complexity to a simple problem. Both have their reasons to exist. …and co-exist.
@AndrewO, please don’t misuse the terms, REST isn’t an architecture, you shouldn’t say “RPC architecture vs REST”. You should say RPC architecture vs ROA (resource oriented architecture).
@Blaxter: You’re right: REST isn’t an architecture. It’s an architectural style, which is why I always said “architectural style” or “RESTful architecture” as in an architecture that follows the REST style.
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.