Re: [xml-dev] REST as RPC done right

[Paul Prescod <paul@prescod.net>]

"Simon St.Laurent" wrote:
> 
>....
> 
> Looking from the bottom of the stack up, they don't look very
> different.  HTTP's relatively easy extensibility (you can conduct RPC
> easily in HEAD requests with custom headers, for instance) suggests a
> serious blurring to me.

There is no debate that HTTP can be a transport protocol for RPC. That's
the whole point of SOAP! Whether you use headers or body, you absolutely
can build RPC on top of HTTP, and if you squint you can pretend that
there is RPC underneath HTTP. But HTTP is not itself an *RPC protocol*.
If it was, nobody would have bothered to invent XML-RPC.

> Is REST an RPC application?  An RPC architecture?  I'd suggest it's the
> latter, built on the former.

I can answer these questions about HTTP but not REST in general. HTTP is
an application protocol which has a syntax and model that you could
imagine was based upon an RPC protocol even though that RPC protocol has
never been defined or given a name.

>...
> > You didn't touch my question about FTP, or SMTP or POP for that matter.
> > You send the UIDL "method" and get back values. Is POP RPC?
> 
> I'd say so.  Looking at it from the bottom of the stack, definitely.

Okay, if POP is RPC then HTTP is too. I don't think you'll find that a
very popular definition of RPC, so I won't use it. But at least we agree
on something. ;)

>....
> HTTP could have been defined on top of a generic RPC protocol without
> harm precisely because it uses the understandings, expectations, and
> mechanisms of RPC. 

HTTP is to RPC as XHTML is to XML. XHTML is an application of XML with
fixed element type names. HTTP could be viewed as an application of RPC
with fixed methods. XHTML is not an extensible markup language. HTTP is
not a remote procedure call protocol. You can invent an extensible
markup language on top of XHTML by hacking the class attribute or using
comments or any number of other hacks. You can invent an RPC protocol on
top of HTTP by abusing the POST body or abusing headers or any number of
other hacks.

 Paul Prescod