Is it fair to describe REST as RPC done right?

I can't say I believe the various denials from the REST camp claiming
that REST is fundamentally different from RPC.  REST has far fewer and
more generic methods than most RPC approaches encourage, and doesn't
appear as likely to create tightly (irrevocably?) coupled systems.  On
the other hand, it clearly has methods and parameters, as well as a
request-response approach.  URIs are not a magic wand for cleaning up
architectures in my experience either.

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.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>