Re: [xml-dev] RESTful operations on document fragments

["Simon St.Laurent" <simonstl@simonstl.com>]

Jeff's apparently having trouble posting to the list, so here's a 
thought-provoking message from him.


-------- Original Message --------
Subject: 	Re: [xml-dev] RESTful operations on document fragments
Date: 	Tue, 26 Feb 2008 13:51:07 +0200
From: 	Jeff Rafter <lists@jeffrafter.com>
To: 	bryan rasmussen <rasmussen.bryan@gmail.com>
CC: 	Andrew Welch <andrew.j.welch@gmail.com>, Simon St.Laurent
<simonstl@simonstl.com>, xml-dev@lists.xml.org


I think Bryan brings up a good point. There are a couple of assumptions
used in this thread so far that I think should be called out:

1) Patches / Fragments are things that are not documents/resources on
their own and should be treated as such (e.g. with their own RESTful
actions)

2) If something is a resource you must use ALL of the verbs on it.

I don't agree with either of these assumptions. Lots of things get
created and you never need to know about them again. Likewise some
representations just exist and don't need to be explicitly created. It
is important to remember that some RESTful actions do have side effects
and that these can side effects can create other resources, delete other
resources, and modify other resources.

I built a simple website called Codeplot to work through some of these
issues. In my case the resource were paste files ("documents"). I
determined that I wanted to handle the modifications to the documents as
revisions and that each revision was made up of a set of patches. I
created nested URIs (which I know are just names) for each of these
things. When you created a document the first revision
/documents/1/revisions/1 was created and patches could be added to that
/documents/1/revisions/1/patches/1. You POST patches which would
ultimately modify the revision, which would change the representation of
the document. For me identifying the fragment was not something I
considered as a standard, I was more interested in the fact that you
needed to look at each of these things individually... why are fragments
different?

As an aside, I ended up using RDDL and namespaces to link documents
together and each "document" had a list of associated resources
"/documents/1/resources/"

Cheers,
Jeff Rafter

On Mon, Feb 25, 2008 at 1:10 PM, bryan rasmussen
<rasmussen.bryan@gmail.com <mailto:rasmussen.bryan@gmail.com>> wrote:

     that sounds somewhat unrestful. I would think basically the theory
     should be that if something is important enough to have a RESTful
     operation done on it, then it is not a fragment of a resource, but a
     resource in its own right that must be included, linked to, or
     otherwise referenced by other resources.

     Just a feeling though.

     I guess what I'm saying is that making an Update url (putting what
     should be a verb into an address) and then processing fragments on
     other resources by whatever the rules of your Update resource are,
     feels to me like the same kind of problem that one sees in markup when
     someone has made something an attribute that should have been an
     element, and then they want to do element like operations on it.


     Cheers,
     Bryan Rasmussen

     On Mon, Feb 25, 2008 at 11:45 AM, Andrew Welch
     <andrew.j.welch@gmail.com <mailto:andrew.j.welch@gmail.com>> wrote:
      > On 23/02/2008, Simon St.Laurent <simonstl@simonstl.com
     <mailto:simonstl@simonstl.com>> wrote:
      >
      > > Anne Thomas Manes wrote:
      >  >  > You could always add an abstraction layer that maps URLs
     (resources)
      >  >  > to document fragments. In your Bible example, you could
     define a
      >  >  > resource for each verse in the document. Therefore you can
     PUT an
      >  >  > updated verse, and a bit of code would then update the
     appropriate
      >  >  > document fragment.
      >  >
      >  >
      >  > I can always create abstraction layer upon abstraction layer.
      They make
      >  >  pretty piles, until they fall over.
      >
      >  How about creating a servlet called something like update, then map
      >  all urls to it:
      >
      >  */update
      >
      >  the call it using the path of the XML that you want to update:
      >
      >  /root/elem1/elem2/update
      >
      >  the update servlet will know what needs to be updated based on
     the url.
      >
      >  A couple of large caveats - I'm not sure if that's even possible
      >  (haven't worked in that area very much) or if that's considered
      >  restful (ditto).
      >
      >
      >  --
      >  Andrew Welch
      >  http://andrewjwelch.com
      >  Kernow: http://kernowforsaxon.sf.net/
      >
      >
      >
      >
 
_______________________________________________________________________
      >
      >  XML-DEV is a publicly archived, unmoderated list hosted by OASIS
      >  to support XML implementation and development. To minimize
      >  spam in the archives, you must subscribe before posting.
      >
      >  [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
      >  Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
     <mailto:xml-dev-unsubscribe@lists.xml.org>
      >  subscribe: xml-dev-subscribe@lists.xml.org
     <mailto:xml-dev-subscribe@lists.xml.org>
      >  List archive: http://lists.xml.org/archives/xml-dev/
      >  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
      >
      >

     _______________________________________________________________________

     XML-DEV is a publicly archived, unmoderated list hosted by OASIS
     to support XML implementation and development. To minimize
     spam in the archives, you must subscribe before posting.

     [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
     Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
     <mailto:xml-dev-unsubscribe@lists.xml.org>
     subscribe: xml-dev-subscribe@lists.xml.org
     <mailto:xml-dev-subscribe@lists.xml.org>
     List archive: http://lists.xml.org/archives/xml-dev/
     List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


!DSPAM:47c404ec255061030411871!