XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RESTful operations on document fragments

Simon St.Laurent wrote:
> Wow.  I can barely look at the PATCH discussions without thinking "Wow, 
> what an incredibly nasty hack," but it's definitely something worth 
> thinking about.
> 
> Maybe it's just my priorities, but a URI format that lets you identify 
> parts of resources seems like a safer path to take than adding a new 
> HTTP method and then having to come up with various formats for doing 
> the patching.  (Not to mention upgrades to web servers.)

I agree that there seem to be two possible approaches:
- Define a new verb (PATCH) and a suitable diff format or formats.
- Use the verbs we have and identify parts of resources with their own 
URIs (making them first-class resources).

Note that I phrased that second one differently than you did, because 
once you come up with a way to assign a URI to a sub-resource, it become 
a full-fledged resources. Going back to your Old Testament example, 
there's no reason that you can't define a URI structure that allows more 
granular updates,
e.g. http://oldtestament.example.org/book/IISamuel/chapter/11/verse/2
You could GET or PUT to that URI to update a single verse. The reason 
people are pushing for PATCH is that they typically want to make many 
such changes in a single operation. So if you wanted to change every 
instance of "thou" to "you", sending the entire document would still be 
quite inefficient, but so would issuing hundreds or thousands of PUTs to 
individual verse URIs.

I don't see how fragment identifiers help at all--as you noted, they are 
only processed client-side whereas the partial update is to take place 
on the server. Updating web infrastructure to change that assumption 
would be far harder than the allowing PATCH.

> Maybe the 1997 XLink approach is worth further pursuit.  (And on 
> reflection, that's probably why I asked the question here - this list 
> has had related conversations in the past.)

I'm not familiar with the 1997 XLink approach. Could you elaborate?

Jim



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS