RE: REST as RPC done right
From: Paul Prescod [mailto:paul@p...] "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. Not that tangible. I am thinking about the use of big fat XML documents of information vs small sets of arguments passed back and forth to build up a complex message. It isn't an issue. >> 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 takes some time and coordination to get an API built up for a business process. Every dimension of participation (two people two departments, two divisions, two companies) makes it harder. We can quickly come up with some function calls, but getting those dimensions to agree to a document type is a lot harder. If all I give them is an address for a document in HTML, life is simple. That is as you have shown, why The Web works. Now given an RPC interface, there is little to negotiate, just much to discover and orchestrate. If the results returned are smaller, I might be more willing to accept some work on my part to handle that than if they provide me a document that requires me to change every process I have to handle it. It somewhat depends on what I want to coordinate and whether I want to do it all up front or a piece at a time. >> 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. UDDI is about as useful as what they say it is for: a yellow pages. Many businesses may be in the yellow pages but don't do business like that. They require, as I've said, qualified customers that are authenticated on use. These are private parties or select memberships. UDDI doesn't do them much good, but like a yellow pages, they may be in there. So I agree. >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. I agree. But then isn't this just as true of using a URI with a query string? IOW, yes, as you say it is a good idea to share addressing or you get the equivalent of the British mail system or a mapping exercise as is done in geo-coded location systems. But below addressing, we are back to vocabulary evolution and it is the same for any system pre document type contracts and a CONOPs. >So the issue is standardization versus the lack of standardization. Too strong a term. It is about aggreements yes. I truly dislike using "standard" like that, but I understand your intent. "Standard" is a link in a chain. I might like to use it, share its use, and so forth, but not to wear it and not to share it as a leash with another. It's just stuff. As an American, I can say with confidence, we have too much stuff. ;-) >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. Ok. I do want to insist that "The Web" is not "The Internet" and that some of these threads are harder if we don't have a good scoping definition for "The Web". It is the same problem as Fielding has with "distributed hypermedia". Given what I see happening, we can certainly have systems that will work well without using "The Web" and still might use parts of "The Web" technology. I believe the Intellink folks had serious discussions about that and a lot of private VPNs do. The problem is the ecology of the Internet, not The Web. Lots of designs really can burn it up (why don't we use two way pipes, stateful protocols etc. - dumb networking, yes?). >> ... 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? Technologies aren't repressive. People are. Insisting on namespaces in XML as core is unless there is an alternative to the http:// thingie. There is (public IDs) so I am satisfied. Insisting on the unification of the world's information resources in "The Web" is a cherry idea and that is not a compliment to the idea. If you aren't, I'm satisfied. But the comment from someone that Public IDs don't solve any problems only means that person may be unaware of some problems. >> 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). Sure. On the other hand, times and requirements change. Understanding why things work is helpful to understanding which requirements to pick at a given time for a given customer. If we really mean what we say about information over implementation, separation of content from process, we have to accept that "The Web" is yet another application and be sure that we don't forge a chain on information, resources, and most particularly, the things they represent in a zealous rage to ensure the ubiquity of "the Web". One of the things that XML plus URIs does, that the web does, is expose a lot of resources to disruptive forces as well. I remember all too well the arguments on comp.text.sgml that if a URI wasn't offered for a document, it didn't exist or shouldn't. That kind of thinking is stupid. You didn't do that but the fellow that did convinced me to question deeply assertions about "the web" and why it's ubiquity must or should triumph over any other solution even if it warps our memory, our recorded history, and the progress of innovation. len
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format