> 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: 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. > 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. 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. 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. -Vincent.
