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

Re: REST as RPC done right

• To: xml-dev@l...
• Subject: Re: REST as RPC done right
• From: Mike Champion <mc@x...>
• Date: Wed, 27 Feb 2002 11:20:16 -0500
• In-reply-to: <1014828130.2260.68.camel@l...>

2/27/2002 11:42:10 AM, "Simon St.Laurent" <simonstl@s...> wrote:


>From my perspective (XMLChucker etc.), REST still looks like RPC.  It
>looks, however, like RPC done far more thoughtfully than usually. 
>Building REST applications requires some thought beyond slapping a
>translator onto an API, and it looks like that thought process is
>valuable.
>
>Does that seem like a reasonable summary?  I don't mind saying REST is
>better RPC.  I have a hard time saying that REST is not RPC.

Well, as you point out on your O'Reilly weblog, XML is not
Aristotelian -- there's not a whole lot of point in trying to
find the cleavage point that cleanly separates RPC from REST :~)

They are alternative architectural styles, and the style's 
aesthetics [I'm sure there's a better word] help shape the
way one looks at the world. REST's aesthetics put a premium on
minimizing the number of "functions" that are remotedly invoked,
and allowing only new ones (e.g. QUERY, TAKE, LOCK/UNLOCK) that
can be defined as combinations of the primitive methods.  Likewise,
it puts a premium on identifying a "resource" via the URI rather
than the "arguments" to the POST "function".

RPC's aesthetics put a premium on minimizing the impedance 
mismatch between programming languages and the web, "hiding the
network" as a number of people here have said.

Neither fully live up to the aesthetics in practice.  For REST,
I'd guess (from the QUERY discussion on the TAG list) that lots
of people are struggling with the reality that query strings
can easily get longer than the URI's that the current web
infrastructure will gracefully handle. For RPC, various minor
hacks to deal with the latency unreliability of the web are
needed (generating a thread to wait for the result of the RPC
call?  Setting up a back-channel for an event-based notification?)

So, I think you've basically got it, but we all need to accept that
this is a "fuzzy" distinction.  With RPC, you hope that the
vendor of your web service "translator" toolkit has coped with the 
latency and unreliability of the Web in an adequate way; with REST,
you have to think about it at the application level, using 
the "raw" web interfaces.

"Where you stand depends on where you sit."  Folks who want to 
sell translator toolkits obviously see a big market in RPC so
that programmers can stop worrying and learn to love the web;
folks who have invested in understanding the Web paradigm and
in developing toolkits that exploit REST (e.g., XPipe, 
RogueWave Ruple, Software AG EntireX Mediator) 
want programmers to stop worrying and learn
to love asynchronicity. 

Since my employer is firmly in both camps, I'm going to waffle :~)

• References:
  • REST as RPC done right
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: RE: XML & government in general
• Next by Date: RE: XML & government in general
• Previous by thread: REST as RPC done right
• Next by thread: Re: REST as RPC done right
• Index(es):
  • Date
  • Thread