On 9/19/06, Vincent <[EMAIL PROTECTED]> wrote:
[...]
> You keep bringing this RPC vs. REST thing up. That's a false
> dichotomy and I think it's just confusing things for you.
It's not a false dichotomy at all. From Fielding's dissertation:
"[Roy's] just this guy, you know." :-)
6.5.2 HTTP is not RPC
[…]
"What makes HTTP significantly different from RPC is that the requests
are directed to resources using a generic interface with standard
semantics that can be interpreted by intermediaries almost as well as by
the machines that originate services. The result is an application that allows
for layers of transformation and indirection that are independent
of the information origin, which is very useful for an Internet-scale,
multi-organization, anarchically scalable information system. RPC
mechanisms, in contrast, are defined in terms of language APIs, not
network-based applications."
So, there is indeed a dichotomy between REST (as applied to HTTP) and
RPC.
No, there's not. He's just defined a particular, constrained,
definition of what "RPC" means to use as a label for what he's talking
about so that he can make the comparison. That's a big part of my
point: "RPC" is almost completely meaningless as a term of art anymore
because it's been so overused with so many different meanings.
> If you must, you should be clear to talk in terms of something
> specific like SOAP or Java's RMI or any number of similar approaches.
> Perhaps itwould help if you thought of the URIs/URLs more like Java or
> CORBA interfaces.?
No, because if I start thinking in terms of Java interface or CORBA IDL,
then I'll stop thinking in terms of addressable resources.
Up to you. That was just a suggestion to help get you away from "RPC"
and on to more specific notions that are closer. Don't forget the
Information Architecture suggestion. :-)
Well, actually, I'm starting to think in terms of services again, but with
a twist: a service becomes a resource when it is associated with a
transaction id:
I never POST or PUT a Foo ; instead, I PUT a FooCreator or FooAction
transaction, get a tx url (with an id) back, and POST it with the
appropriate state information. The server guarantees that a transaction
cannot be POSTed twice (idempotence), and I can even retrieve the
result/status of a transaction at a later time.
You're creating a relatively arbitrary, artificial distinction between
"resource" and "service" (ala the distinction between "code" and
"data"). If that's helpful to move forward then that's good but I'd
suggest at least keeping the fact that that's artificial in the back
of your mind. IMHO, a better model is to think in terms of identity
and action.
This is where I'm at right now. I'll see where it leads me. I'm not yet
convinced of the benefits of this approach over XML-RPC (I can achieve
idempotence by passing a tx id to all RPC's),
but I'll keep exploring RESTful architectures for now. This forum has been
very valuable so far. Thanks.
Cool. Good luck.
John
