The most interesting thread on the rest-discuss list in a long time begins with a simple request for assistance: How to implement a query with a long query string? Most of the RESTigentsia weighed in before it was all over, and Roy Fielding gave Mark Baker the business, though it wasn't deserved.

And I learned something. As Roy pointed out, I had not appreciated the role of "hypertext as the engine of application state".

This idea illuminates a whole world actually.

The HTTP application protocol -- the type section for a REST application framework -- enables lots of different applications all to run on the same fabric. Roy points out, in applications using HTML, clients know something about how to process the GET, based on the context. Both the <a> and <img> tags retrieve resources using GET. Browsers know how to render the returned entity differently depending on whether the HTML referenced the resouce using <a> or <img>. REST folks use "self-descriptive" to refer to entities like HTML documents, that indicate to knowing agents how to process the resource references in them.

And lots of other agents are out there on the web, non-HTML agents, knowing nothing about how to process <a> and <img> tags. And these agents will ordinarily never encounter those tags. If you've written an agent to process some XML dialect, your agent normally navigates among documents of that type.


So all kinds of applications out there are blissfully navigating via HTTP, and mostly they don't know how to make sense of one another's resources.

(For the case of POST, every application -- heck every resource -- can have wildly different semantics. On his blog, Mark Nottingham gives an excellent discourse on the topic).

So the REST world is this world of a few verbs, and zillions of nouns. And the nouns form clusters around the semantics they honor. In the case of HTTP, you have clusters of nouns that understand HTML. You have other clusters that understand XML+Xlink. Still others understand XML+RDF. And a jillion more understand their own custom media in whatever idiosyncratic way the application authors wanted. The apps in each cluster all play on the web, oblivious to the apps in the other clusters.




`

XML vs Relational: Fabian Pascal puts it best in this article. The man says what he means.

I really like that Oracle XDB. If you are going to use an XML DB it looks like their shredding technique comes as close as possible to automating the decomposition of documents onto tables. But only top level documents get inserted into tables -- and those tables are of "XMLType". XDB describes nested elements by new types --domains-- it constructs: good. But I cannot see the storage layout for instances of those types: not good.
Finally, I was hoping XDB would permit me to annotate the XML schemas to fully map instanced documents onto tables of my own design, or onto legacy tables -- but that is not the case. I could write triggers of course to map document constituents onto the tables. But I already could do that!

Who knew that Oracle were RESTafarians?

The Oracle 9i/10g XML DB (XDB) exposes a WEBDAV interface. You can drag and drop XML files into folders you can open using Windows Explorer. XDB will notice the new file and "shred" it -- decompose it onto tables it creates at "design time", that is, when you register an XML Schema file for the XML types you'll deposit in the repository.

I am deeply suspicious of XML databases, and of object databases. And XDB applies Oracles object-relational technology to the problem. It really bothers me that there is such a thing a "table type", and that XDB stores XML documents in tables of type XMLType. On the positive side, you can have a column of XMLType or any object type, and that does conform to the relational model (here's a random C. J. Date take on that).



And it's great I can just fire up my dbms and use GET, POST, PUT, DELETE, and the DAV extensions to stuff data into the db.

And if that dbms decomposes that data and enforces constraints, then the back-end is half done.

+1 on the Oracle XDB.

Apropos of nothing, just ran across this nice site about Honeywell Multics mainframes and those who loved them, or actually mainly just lived with them in a loveless marriage.

Java Server Faces. Finally someone who knows what they are doing has designed a decent application framework.

Here is my favorite documentation from Struts tags:


put - Put an attribute into tile/component/template context.
Define an attribute to pass to tile/component/template. This tag can only be used inside 'insert' or 'definition' tag. Value (or content) is specified using attribute 'value' (or 'content'), or using the tag body. It is also possible to specify the type of the value :
string : Content is written directly.
page template : Content is included from specified URL. Name is used as an URL.
definition : Content come from specified definition (from factory). Name is used as definition name.
If type is specified, it is taken into account by 'get' or 'insert' inside the inserted tile.
If 'type' attribute is not specified, content is 'untyped', unless it comes from a typed bean.

Note that using 'direct="true"' is equivalent to 'type="string"'.


Here is a nice quick JSF quick start:
JSF (Java Server Faces) Visual Tutorial

So you want to build a REST application, but you find you have to put all this javascript in the views to construct and POST xml. Nobody knows why HTML 1.1 doesn't have the capability to POST text/xml, but it just doesn't; and if you're waiting for native XForms support in browsers, forget it. So we are stuck with good old application/x-www-form-urlencoded. Learn to love it. It is just another serialization mechanism. We could have whole books and architectures on the topic of "Object-URL Encoded Form Data Mapping." We could have an Apache OUB (Object-UEFD Bridge).

So what is it exactly that we can do with xml, that we cannot do with URL encoded form data? Why get hung up on the type of the resource representation?

So you build your service and it accepts two kinds of representations: xml or UEFD. Either can represent the same resource with equal fidelity. Quibble with me about the hierarchical relationships you can represent in xml. You can represent hiereachies in UEFD using your own patterns (and interoperability really isn't the use case here).

Is it me or is it Hibernate?

It's very early in the relationship. But some things that ought to be very simple turn out to be hard. I had a bean property of type java.lang.URI, persisted in a table column as a varchar. How hard could it be to automate this mapping? Well, kinda. I had to create classes URIAccessor (implements PropertyAccessor), URIGetter (implements Getter), and URISetter (implements Setter). PropertyAccessor has two methods; Getter has four methods (two optional); Setter has three methods (two optional). So to persist a URI I had to create three Java classes and implement at least five methods. Mapping a URI class to a String column ought to be simple.

This is more troubling: I have a table having a composite primary key; the key columns are themselves foreign keys. This is the natural organization of the problem. The Hibernate documentation indicates Hibernate supports composite primary keys, but there are constraints on your Java class implementations... well, you can see what you have to do here: http://www.hibernate.org/hib_docs/reference/html/components.html.

If I have to go to that much trouble to contrive java classes that comport to my logical data model, I have to wonder why I am using such a tool in the first place. This O/R mapping tool is supposed to be *easier* than writing SQL!

The overriding principle I need in any O/R mapping is that the LDM ought to be inviolable. I don't mind writing any kind of hacky class methods to support that LDM. I want my data model to survive any program I write. Fifteen years from now programming languages will be more advanced, and I want my LDM independent of today's idioms.