[
Lists Home |
Date Index |
Thread Index
]
After all the hundreds of posts (this time around) on this subject, I still
am not convinced that most of the things that have been claimed to
differentiate RPC from REST actually do that. I suspect that the
differentiators are very few, and very simple in concept.
When I first learned about xml-rpc a few years ago, my first reaction was
that it offered a way to send form-like data that was more structured than
name:value pairs. It seemed to be a natural evolution of form data, like
going from CSV to XML. The fact that you could arrange to write code (at
least in Python) that looked exactly like a method call on an object was
sort of cool, and made things seem more familiar, but didn't seen essential.
Then SOAP got complicated and blurred matters.
Consider this: when you send an HTTP request, GET or POST, with query
parameters, you are invoking a lot of network operations that you don't
know about, and asking the server on the other end to perform some
operations, selected by the parameters, that you don't know about, finally
perhaps getting some data back. We have a metaphor that we are asking for a
"page","document", or "representation of a resource", but really we are just
getting data. It may be made up on the fly, who knows?
When you make an RPC call, you invoke a lot of network activity that you
don't know about, and you ask the remote server to use a series of
parameters to perform some operations that you don't know about, finally
perhaps getting some data back in some structured format.
What's different? Not that you sent parameters to a server over a network.
Not, probably, the complexity of the parameters. Even the supposed
difference between a "representation" of a resource vs. function invocation
seems to me to be a red herring. It reminds me mostly that you can view
almost any system from a procedural- or a data-centric view, and sometimes
one or the other will be more convenient. Which one is most productive is
likely to be partly development style and partly what the invariants are in
the system.
The statements that you should not expose the raw resource to the network's
tender mercies are only restating that good practice used for years in the
relational database world, where you know you should expose views rather
than tables for just these reasons.
What, then, is left as a differentiator between REST operations and RPC
operations? It seems to me only and exactly the few key things that
differentiate REST itself from other network architectures. Universal
addressing, a small set of universally understood operations (e.g.,
GET,POST,PUT, etc.), a small and relatively simple suite of network control
functions, right?
Viewed in this way, you can almost run a checklist, and the results seem to
align well with what Paul Prescod has been saying. Taking SOAP as an
example, does it use universal addressing? Well, yes and no. It uses a URL
to get to a server, but then can have other routing information embedded in
it. Does it use a small set of universally understood operations? Well,
once you get past the original POST, no it doesn't.
OK, but so what? It seems to me that a REST system, being simple and highly
public, is open and easy for people to attempt to hack or spoof, since there
are only a few well understood commands. Several people have provided good
examples in the last few days on the list. The other side of the coin is
that protection is easier to understand and incorporate, since the number of
possibilities to deal with are smaller than for some other network
architectures. This, too, has been remarked upon.
Just the reverse, then, would seem to apply to an (non-REST) RPC-based
system. Being less open (or not open at all if we follow Len's advice for
highly important material), and both more complex and less commonly
understood in its commands, it should be less subject to successful hacking
and spoofing, but harder to protect against when it does occur.
What's the bottom line here, which way should be "better", more secure? Not
obvious, not to me at any rate. But then I don't have practical experience
building large systems like this. Simplicity, though, is likely to be
better for building large numbers of large, reliable systems apart from
security, and this would favor REST, wouldn't it?
Cheers,
Tom P
|
