Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: [SPAM] Re: RESTful operations on document fragments'
![RE: [SPAM] Re: RESTful operations on document fragments'](/images/get_stylus.gif) Would someone comment on why WEBDAV approaches are not being considered in this thread? A discussion of what I would take to be a RESTful approach to HTTP extensions begins at http://www.webdav.org/specs/rfc2518.html#http.methods.for.distributed.au thoring Resources are discussed at http://www.webdav.org/specs/rfc2518.html#data.model.for.resource.propert ies and collections at http://www.webdav.org/specs/rfc2518.html#collections.of.web.resources Dale Moberg -----Original Message----- From: Simon St.Laurent [mailto:simonstl@s...] Sent: Tuesday, February 26, 2008 6:09 AM To: xml-dev@l... Subject: [SPAM] Re: RESTful operations on document fragments' Jeff's apparently having trouble posting to the list, so here's a thought-provoking message from him. -------- Original Message -------- Subject: Re: RESTful operations on document fragments Date: Tue, 26 Feb 2008 13:51:07 +0200 From: Jeff Rafter <lists@j...> To: bryan rasmussen <rasmussen.bryan@g...> CC: Andrew Welch <andrew.j.welch@g...>, Simon St.Laurent <simonstl@s...>, xml-dev@l... 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@g... <mailto:rasmussen.bryan@g...>> 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@g... <mailto:andrew.j.welch@g...>> wrote: > On 23/02/2008, Simon St.Laurent <simonstl@s... <mailto:simonstl@s...>> 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@l... <mailto:xml-dev-unsubscribe@l...> > subscribe: xml-dev-subscribe@l... <mailto:xml-dev-subscribe@l...> > 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@l... <mailto:xml-dev-unsubscribe@l...> subscribe: xml-dev-subscribe@l... <mailto:xml-dev-subscribe@l...> List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php !DSPAM:47c404ec255061030411871! _______________________________________________________________________ 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@l... subscribe: xml-dev-subscribe@l... List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
