[
Lists Home |
Date Index |
Thread Index
]
On Monday 11 February 2002 04:16 pm, Paul Prescod wrote:
> That's a rhetorical strategy that won't work. Whatever virtues we
> point out of REST, RPC people will point out that you can do the
> same thing in RPC if you just structure your method calls right. For
> instance you could use a few verbs, as REST does. You could make
> them generic, as REST does. You could always pass a URI as the first
> argument. You could build client-side messages as XML documents and
> pass them through RPC as content-bodies, as HTTP does. etc. You
> could reinvent it all in a new syntax two levels above HTTP. And it
> would work.
Actually, I think Mike has pointed out the key here though: REST is an
*architecture*. If you used RPC to *implement* REST, it would be just
as well be called REST as REST using HTTP. I think that is a crucial
point.
The REST *architecture* has merits for some classes of problem, no
doubt about it. I don't think anyone would claim that it is applicable
to *all* classes of problem. REST over HTTP is equally usable for some
subset of the problem domain to which REST is applicable, and equally,
I don't think anyone would claim that it is applicable to *all* REST
problems.
This really reminds me of the DOM days.... people can't see the
architecture for the implementation, or the implementation for the
problem domain.
|
