Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Exposing resources/services vs hiding implementation detai
 On Apr 5, 2005 6:31 PM, Leigh Dodds <leigh@l...> wrote: > I don't see how defining a public URL space exposes any details about > my application structure. I've done it, for both human and machine > oriented interfaces, and you can't tell from the url structure or > response formats what my backend is doing. Or even if the entities in > the URI map 1:1 with entities in my database schema. I interpreted Bill's original post as arguing that one should expose actual implementation objects, tables, etc. as URIs. We cleared that up -- he was talking about abstractions or "domain objects" a la Amazon.com's book-specific URIs that one can exchange, bookmark, etc. and not the physical tables where all this stuff resides. If the backend is hidden, behind URIs, services, or whatever, my concerns about information hiding are irrelevant. If the entities in the URI map 1:1 with your database schema, well, it seems like an unnecessary risk to me, but I don't claim to know much about security. Judging by the state of the industry, I'm not sure that very many of us do either :-) . My main reason for starting this thread was not to argue against this, but to wonder why several people are so certain that having a single message dispatcher URI is a bad idea, irrespective of whether exposing all the individual resource URIs is a good idea. I'm not sure my strawman has been demolished yet: The SOA dogma is to expose the service and the service contract to the client,and hide everything else. That seems to reflect decades of best practice, back to "information hiding" in the days when Structured Programming was the One True Path to software quality. I'm not sure what's wrong with that dogma, other than the fact that REST advocates making "domain objects" visible via URIs and having clients manipulate them by transferring representations. Why is that supposedly better? What's the evidence? My motivation in all this uber-permathread is that I opposed the notion that was popular 3-4 years ago of extending the COM/CORBA/RMI distributed object paradigm to the Web; I agreed with the RESTifarians that it wouldn't scale, wouldn't leverage the Web infrastructure, all the classic arguments that appear to have been validated by Amazon, Bloglines, Flickr, etc. But now I'm questioning the currently popular notion that the Web architectural style is generally suitable for enterprise scenarios where COM/RMI/J2EE/etc. are entrenched. In these, information is often confidential, lots of real money is on the table and armies of slimeballs want to steal it, there is a more even balance between readers and writers (making all the cacheing goodness somewhat irrelevant), and the data is consumed by mission-critical programs that can't just sigh and click on the next link if there is a 404, or try again later if there is a timeout. MAYBE the Web architecture principles apply here as well, obviously many people think they should. I'm skeptical, and asking for solid arguments and concrete success stories. 
|
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
|
|||||||||
