Hi!
We are planning to do an in-house system offering data to various departments.
The data will be held in a database (oracle) in a conventional database schema
with tables, triggers, integrity constrains and whatnot.
Now, we don't want to give the whole company full access to the database
and we want the minimum software requirements, so using ODBC or
such is out of the question.
Therefore we settled on offering the data as XML data via http.
The database maintains parts data. Initially we think of less than
5000 parts (each part having various attributes and associated data)
but we don't want the system to become unusable if it turns out we
host 100.000 parts because some other department decides to use
our system too.
However, we don't know much about this and I'd like to put up our
ideas for discussion.
The plan so far looks like this:
The database has multiple "root" tables so there will be multiple
paths to the data objects. For instance, you can look up a part
and ask it for the safety instructions or you can look up a document
and ask it for the part(s) it is supposed to describe.
The clients will connect to the apache in front of the database,
and get authenticated there.
As a first idea we plan to do data read access to be XPATH-based:
"get
http://ourdatabase/datastore?XPATH=/parts/part[@name="PART_NAME"]/datasheet/@format"
should return an XML document with the nested nodes (containing
nothing more than the path information in the xpath expression)
and the format name in it:
<parts>
<part name="PART_NAME">
<datasheet format="US-LETTER"/>
</part>
</parts>
The idea here is to make it possible to select more than one node
by using wildcards.
If a whole node is to be returned, we plan do return the attributes,
the node data and any child nodes as references. Does XML have things
like <href...too?
Is there a better way?
Non-XPATH would probably work too, but we hesitate to offer
just single node access and a full listing. And we don't want
to reinvent our own search parameters (match/regexp/whatever).
The whole thing should be intuitively usable by anyone being
able to read a XML book and the only thing we want to publish
as documentation is a poster with the hierarchy.
For DELETE, XPATH is realistic too, IMHO, even if dangerous.
For put and post, XPATH doesn't make sense, does it?
Should we insist on replacing complete nodes only? I think that's realistic
as a client can easily request a node, do a small modification and then
put up the result. But I see that we here use conventional URIs
and for querying XPATH expressions.
Is there any way to get this symmetrical?
Also, while posting and putting, the database has to do a few sanity
checks and translate this into one or many update statements into
tables.
Is using XPATH expressions RESTful at all?
Or should we totally forget about XPATH, do the hierarchies and that's it?
Maybe add wildcards to the URIs? But the return values for single node
access and node set access are IMHO very different. I can't return several
independent text blocks, can I?
We don't have any specific customer requests so we try to maximize
"cleanliness" of design while still trying to keep the whole thing
scalable in case it catches on.
Also, when doing a request like get "http://.../xxx/yy/" the idea is to
return the nodes http://.../xxx/yy/* . What would a RESTful system
return? All nodes or just an array of href's?
Lots of Greetings!
Volker
--
For email replies, please substitute the obvious.
