[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Evaluating RPC versus REST

• To: 'Leigh Dodds' <ldodds@i...>, xml-dev <xml-dev@l...>
• Subject: RE: Evaluating RPC versus REST
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Tue, 26 Feb 2002 09:27:42 -0600

What are the local and long term costs for optimization 
for the global case?

What are the efficiencies gained by tight coupling of 
enterprise (intra and extra) processes vs the loose 
couplings based on standard document types?  

Even with a global namespace, the same questions 
have to be asked.  Use of a global namespace is 
not the issue as far as I can tell.   You may  
have a hard time defining "distributed hypermedia" 
to everyone's satisfaction.   See Dexter Reference 
Model.

len

-----Original Message-----
From: Leigh Dodds [mailto:ldodds@i...]

Fieldings dissertation presents a number of architectural styles, and 
evaluates each of them within a defined context: distributed hypermedia.
However he doesn't cover RPC in this classification (correct me if I'm wrong, 
I've only read through the whole thing once). RPC is mentioned in a 
later section [1] though.

So why not define RPC as an architectural style -- in all likelihood derived 
from others that Fielding does classify -- so it can be objectively compared 
to REST?

Might that not provide a clear evaluation of the architectures separate 
to any issues with the specific technologies (SOAP, WSDL, .NET, etc)?

It may be that RPC doesn't compare favourably to REST in a distributed 
hypermedia environment, but does in others (e.g. the canonical 'inside the firewall' 
example). It may be that RPC *can* be used in successfully used in some environments 
across the public internet, just not distributed hypermedia. It may 
be that these can exist side by side, although no doubt there will be efforts [2] 
to make the distinctions disappear.

Identifying the suitable contexts for different architectural styles seems like a 
best practice discussion -- there will be no single right answer.

At this point we could argue over whether there ought to be several different 
Internet architectures (i.e. "there is no (single) Web"), or whether every effort should be 
made to optimise for the general case, i.e. REST. Personally I'm in the latter camp.

[1]. http://www1.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_5_2
[2]. http://wsui.org/

• Follow-Ups:
  • RE: Evaluating RPC versus REST
    • From: Mike Champion <mc@x...>

• Prev by Date: Evaluating RPC versus REST
• Next by Date: Re: XInclude & Document Function.
• Previous by thread: Evaluating RPC versus REST
• Next by thread: RE: Evaluating RPC versus REST
• Index(es):
  • Date
  • Thread