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

[Paul Prescod <paul@prescod.net>]

"Bullard, Claude L (Len)" wrote:
> 
> REST is RPC with primitive methods and strict adherence to
> a global namespace.  Further, it depends on sharing vocabularies
> even if they are as small as a query name and a few arguments.
> So do all of the alternatives.  They vary by top-down vs bottom-up
> evolution of the vocabulary.

I agree up to the last sentence which I do not understand.

> Still, I don't think it's quite that easy.   What do you want to support?
> Browsing and exploration (tight coupling to navigation) or computing a
> result?  I think you can do either with REST with more work, and
> the second with task-specific RPC with more coordination over time.

Can you demonstrate that the "more work" is sufficient to be significant
in any system larger than getStockQuote?

> It comes down to building with generic methods.  Both can
> use a global namespace.  (Are the critics of UDDI really
> fussing about GUIDs?) 

UDDI is useless regardless of its technical architecture, because its
scope is way too broad. The promises made for it are unattainable.

As far as GUIDs, the problem isn't GUIDs versus URIs. The problem is
that one service uses GUIDs as the first parameter for addressing.
Another uses XPaths as the second parameter. A third uses integer
counters as the third parameter. A fourth uses opaque CustomerID strings
as the second parameter. *Even* if these services unify their XML
description for "customer", integrating the services is necessarily a
programming task because I must map between the different namespaces.
Let's say I want to sell you a product that generates reports about
customerIDs in a known XML vocabulary. I can't just sell you a
shrink-wrapped product. I have to teach you how to integrate it with
your proprietary addressing scheme. Whereas if the services used URIs
then you would just present the program with a list of URIs and it would
go to work.

So the issue is standardization versus the lack of standardization.

> ... At this time, I tend to favor REST
> for sheer ease in the beginning of the design task
> and ease at the beginning often makes for a sustainable
> effort.  But not at the cost of being told other protocols or
> design architectures don't have a right to exist on the
> Internet. 

Who said that? The closest I can come is to say that it is highly
questionable whether the W3C should help to standardize a technology
that is most often used to balkanize the open, standarized namespace as
I discussed above. But I wouldn't deny SOAP etc. a right to exist.

> ... That part is dumb.  Impress over imprimatur.
> Still, that simply means "the web" is not the Internet
> and that those who want to defend "the web" are either
> forging chains or building bulwarks.  Caveat vendor.

I don't know what you're talking about. You've suggested on a couple of
occasions that the request that you use a standardized addressing syntax
is in some sense repressive or counter productive. Can you please be
more specific?

>...
> If HTTP went away, event is URIs went away, would be
> still have a hypemedia system on the Internet?

Yes. I used hypermedia systems on the Internet before the Web. But the
Web caught on because of URIs (then called URLs).

 Paul Prescod