Comparing the "Economics" of REST and RPC

David Orchard
Thu, 16 Aug 2001 14:09:55 -0700

If you're going to criticize us lemmings, provide an alternative or 
justification instead of telling us how stupid we are.  Honey, not vinegar.

I'm a builder of real Internet systems that people depend upon for business 
as well, and probably a lot of other people around are as well.  What would 
be helpful is specific reasons for your beliefs.  You alluded to things 
like interface versioning in other messages, and you mention dependencies 
in this message.  You regularly write theses, etc. so I was wondering if 
you had any documentation or collection of documentation/emails/whatever 
that fleshed out your position.

As a person who has regularly spoken against the hype of XML/Web Services = 
swarms of self-healing autonomous smart services (or the ilk), I think we 
might share a common view, though I'm interested in understanding your 
specific reasons.  I typically point to inconsistencies in the overall 
deployment of Web/XML systems in my criticisms, such as: 1) how do firewall 
admins deal with SOAP/HTTP; 2) XML/XSLT etc. was not really design for 
server/application-centric computing; 3) XML itself isn't even finished, 
what's the processing model? 4) why are there 4 data models for XML? 5) How 
does a system deal with XML from end-to-end, etc

Dave Orchard
XML Architect, Jamcracker

On Thursday, August 16, 2001 1:29 PM, Roy T. Fielding 
[] wrote:
> > We're certainly moving towards XML for control representation in a big 
> >  I don't know of a significant or sincere alternative to SOAP et al.
> Lemmings do that too.
> > Does your REST work cover why you hold this belief?
> No, REST is an architectural style -- it does not dictate protocol 
> I hold that belief because I spend a lot of time building real Internet
> services that people depend on for business.  XML introduces hundreds of
> hidden dependencies within an integrated system that can be seen when
> you do performance profiles and protocol traces.  That can be managed
> within an application context, but not within a transfer context.
> ....Roy