Discussion in 'XML' started by Volker Hetzer, May 30, 2007.

  1. 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:
    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:
    <part name="PART_NAME">
    <datasheet format="US-LETTER"/>
    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

    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!
    For email replies, please substitute the obvious.
    Volker Hetzer, May 30, 2007
    1. Advertising

Want to reply to this thread or ask your own question?

Similar Threads
  1. Lin Jen-Shin
    Lin Jen-Shin
    May 6, 2010
  2. Lin Jen-Shin
    Lin Jen-Shin
    May 21, 2010
  3. Lin Jen-Shin
    Lin Jen-Shin
    Jun 11, 2010
  4. Markus Fischer
    Markus Fischer
    Sep 10, 2010
  5. 2ni

    REST API and the location bar

    2ni, Jun 14, 2005, in forum: Javascript

Share This Page