Re: REST as RPC done right
"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
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