In the REST track, it was said (repeatedly) that WS-* circumvented the “design” of the Web and thus ignored the Web’s innate capabilities (for example, Jim Webber’s slides, #14). Sure, architectures often encapsulate subsystems for the sake of abstraction, which brings me to my point. Just as WS-* tunnels the Web, component architectures often manage persistence by tunneling a relational database. The query processing power of the database is rarely directly accessible by the solution consumers.
My company sells ERP applications, which are used to run enterprises. Our customers demand commercial RDBMS products because, in their minds, our application maintains their data. That data must be in a store they understand and (feel they) control. These enterprises invariably invent ways, bypassing our code, to productively reuse their data in ways their vendor (us) did not foresee. Conceptually, I don’t see much difference between this kind of reuse and the serendipitous reuse described by Roy Fielding (and summarized nicely here [pdf] by Steve Vinoski). If their data was stuck in an opaque blob, accessible only through our APIs, we wouldn’t sell very many systems.
But like I mentioned earlier component architectures relegate relational databases to soulless “persistence stores” devoid of independent capabilities. The conventional wisdom for component design says data is private to the component and access only through a public interface. But I think people have tended to militantly privatize data, denying support to anyone daring to connect to the data on their own. That practice is one reason some solutions are opting away from an RDMS stores altogether and going with more OO-friendly stores.
The obvious problem with taking this tenet too literally is that access to data is limited to a preconceived set of interfaces. Reusing data in unforeseen ways is accomplished by sneaking around the application or rebuilding it to accommodate new requirements. Databases are rather smart engines designed under an assumption that data, once created, is then retrievable in countless, unforeseen ways. Nevertheless, architectures are burying perfectly good query processors under layers of abstractions, objects, and interfaces. Being pushed to the bottom of the stack is one reason that physical data models are actually devolving, IMO, but that’s another story.
The public “API” for a RESTful application is its URI address space. You can invent a list of URIs mapped to resources and state sequences all you like. But the reuse potential is limited to whatever your callers can get out of that URI space. Like REST, SQL databases have a uniform interface. But look at the practically unlimited variety of resources you can access. Obviously, a REST URI shouldn’t be a SQL statement and I’m not trying to shoehorn XQuery into a URI. All I’m saying is that a URI space can incorporate parent-child and relational characteristics from a data model – using relational database behavior as a guide. This has been a key aspect (for 8+ years, BTW) in developing URI strategies for our products.
The emerging specs and toolkits, like WADL and WCF, feature URI template constructs. But URI templates have no notion of resource linkages (parent, relational, or otherwise) and that limits their effectiveness. At QCon, there was little consensus that WADL was the right way to describe a REST application. But I think REST description
