[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RESTful operations on document fragments
- From: "Simon St.Laurent" <simonstl@simonstl.com>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Fri, 22 Feb 2008 17:32:32 -0500
Friday evening is usually a bad time to start a conversation, but this
may be kind of appropriate to a Friday evening.
I've been enjoying working with RESTful operations in Ruby on Rails and
some of the XML they can generate [1]. At the same time, I'm thinking
about various projects I'd like to work with that use XML documents as a
foundation rather than relational databases - it'd be great to have
something like ActiveTreebranch to go with ActiveRecord.
Before I even think about the Ruby side, though - and I'm a long ways
from that - I'm wondering about a more basic problem.
RESTful operations are performed on resources identified by URIs. Those
URIs can - if I'm reading HTTP 1.1 [2] right - include a query string
even when they're used with PUT, POST or DELETE. (I need to do some
experiments to verify that this actually works - I hadn't considered
doing it before.)
However, document fragments are typically identified through the
fragment identifier, the #xxxx that is the usual domain of tools like
XPointer. The fragment identifier is not normally sent to the server,
and is supposed to be processed on the client side, depending on the
MIME type of the response. [3]
That makes good sense in the GET context which has been typical of most
Web operations. However, it raises a challenge in the RESTful
processing context.
Am I required to perform RESTful operations only against a complete
resource?
For example, if I want to fix a typo in one verse of the Old Testament
XML file, should I really send the entire 3.3MB document, or is there a
way to convey in RESTful parlance that an update is only for a portion
of a document?
I'd love to be able to issue GET, PUT, POST, and DELETE against document
fragments, but the fragment identifier approach isn't going to work, and
I've not (yet) found anything nearly as expressive that goes into the
URL outside of the fragment identifier space.
To give a practical example, having even simple RESTful access to
fragments using a subset of XPath would make it much simpler to write
Web-based editors for manipulating (writing, editing, etc.) book content.
I did find some very simple recent work from Joe Gregorio [4]. That
seems both to have gotten pushback and limited itself to id-based
fragments.
The problem of resource granularity seems like a question that is
starting to need a more general and at least somewhat flexible solution.
(Rails' current RESTfulness can dodge this because each database record
is treated as a resource, and that's the usual granularity developers
work at. It only gets weird when you look beyond regular tables to
irregular documents.)
Thanks,
Simon St.Laurent
Retiring XML troublemaker
http://simonstl.com/
[1] -
<http://www.oreillynet.com/xml/blog/2008/01/rails_rest_and_anarchist_xml_1.html>
[2] - <http://www.faqs.org/rfcs/rfc2616.html>
[3] - <http://www.w3.org/DesignIssues/Fragment.html>
[4] - <http://bitworking.org/news/296/How-To-Do-RESTful-Partial-Updates>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]