Hi Vincent, > 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.
He talks about "significant difference" between HTTP and traditional-RPC (like RMI or CORBA) and not about "dichotomy" which means total separation with no overlap (http://en.wikipedia.org/wiki/Dichotomy). If not, how would you explain the existence of XML-RPC with use HTTP in a limited but correct way? Now, it seems like you are forcing reality into your own simplistic model of REST and HTTP ;-) > 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. Not all applications require this level of transactionality/atomicity. In those cases, directly using PUT to create a resource is just fine as putting the same representation multiple times as no visible side effect. > 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. Consider this reference from the HTTP specification illustrating that a resource may very well be an action/process/service: "POST is designed to allow a uniform method to cover the following functions: [...] - Providing a block of data, such as the result of submitting a form, to a data-handling process;" http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 I suggest that you view everything as a RESOURCE, then consider two main types: - ENTITY RESOURCE : similar to EJB entities, data objects - PROCESS RESOURCE : similar to EJB sessions, XML-RPC/RMI/CORBA services It seems to me that you were influenced by the common opposition between REST/HTTP and SOAP. SOAP is a special case because when it uses HTTP, it uses it as a tunnel without care for its true semantics (this may have evolved recently with improved HTTP bindings?). XML-RPC simply sends plain XML documents over HTTP-POST which is RESTful IMHO. So, you could use a mix of XML-RPC oriented resources for your PROCESS RESOURCES and more traditional REST/HTTP for ENTITY RESOURCES. Thanks, Jerome
