[
Lists Home |
Date Index |
Thread Index
]
"Simon St.Laurent" wrote:
>
> Is it fair to describe REST as RPC done right?
>
> I can't say I believe the various denials from the REST camp claiming
> that REST is fundamentally different from RPC. REST has far fewer and
> more generic methods than most RPC approaches encourage, and doesn't
> appear as likely to create tightly (irrevocably?) coupled systems. On
> the other hand, it clearly has methods and parameters, as well as a
> request-response approach.
I'll pick the nits that Mark wouldn't. It isn't that REST methods are
more generic, it's that they _are_ *generic*. If a method doesn't make
sense for most or all resources then it shouldn't be a REST method.
> ... URIs are not a magic wand for cleaning up
> architectures in my experience either.
That's a little too vague for me to be able to say much about it.
> From my perspective (XMLChucker etc.), REST still looks like RPC.
From my perspective, XMLChucker looks like RPC. ;)
REST requires the generic intent of the message to be available in a
manner that is visible in the protocol and thus to intermediaries. RPCs
do not and as far as you have described, XMLChucker does not. So to me,
XMLChucker is more like an RPC protocol. (assuming it allows return
results, which it may not)
In my mind, the defining characteristics of RPC are a) a single endpoint
supports an arbitrary number of methods b) the endpoint is allowed to
invent its own methods and c) the endpoint returns values based on the
method name and method inputs.
If HTTP is RPC then I would say FTP is also. HTTP calls them "methods",
FTP calls them "commands" but the important thing is that they are
defined *in the standard* (modulo extensions) rather than being defined
by the end-points.
And it is because they are defined in the standard that intermediaries
have a hope of understanding them.
Paul Prescod
|
