Embrace, Extend then Innovate
Joe Gregorio: So there you have it, outside of six open questions, a nice RESTful way to do partial updates.
James Snell: Blech…....
Placing verbs in URIs definitely smells bad.
With HTTP PUT, the the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. Having some servers interpret the removal of elements (such as content) as a modification, and others interpret the requests in such a way that elided elements are to be left alone is hardly uniform or self-descriptive. In fact, depending on usage, it is positively stateful.
I’m fine with a server choosing to interpret the request anyway it sees fit. As a black box, it could behave as if it updated the resource as requested and then one nanosecond later — and before it processes any other requests — fill in missing data with defaults, historical data, whatever. My concern is with clients coding with to the assumption as to how the server works. That’s called coupling.
Don’t get me wrong, there are use cases where partial updates are desirable, even when that comes at a cost in terms of relaxing one or more of RESTs constraints. But such should be possible without violating the spec or spirit of either HTTP’s PUT or Atom’s entry.
I’ll close with a concrete use case: consider a AtomPub server that supports categories. Imagine an entry that currently has two categories. How would you add a category? How would you delete one? How would you delete them all?
What if the server doesn’t understand the XPath bit? I may be missing something, but it seems like it’d end up deleting everything if it shares a URI with the original resource and the XPath part isn’t understood. Certainly not desired behavior.
Posted by Bob Aman at
How To Do RESTful Partial Updates
There are times when you have a large representation of a resource and only want to edit a small part of that resource. Wikipedia is a good example, where many entries in the encyclopedia are very long and you don’t want to wade through all that...Excerpt from BitWorking | Joe Gregorio at
“Don’t get me wrong, there are use cases where partial updates are desirable, even when that comes at a cost in terms of relaxing one or more of RESTs constraints.”
Name one :)
“But such should be possible without violating the spec or spirit of either HTTP’s PUT or Atom’s entry.”
It is possible; it’s possible to do for types other than Atom entries*; it’s possible to do within AtomPub; it’s possible to do it without a REST Fail. If I could get one non-working weekend, I’d knock up an ID.
What is harder is doing it for XML, particularly stuff like Atom. You tend towards in inventing XML diff formats to avoid sending busted content (remember all the hassle we had with AtomPub and legal Atom on the create step?). Incidentally RDF trumps XML for partials; more anon.
Posted by Bill de hOra atcgrand on Joe Gregorio: How To Do RESTful Partial Updates
[Tim Bray’s concerns]([link]): > I’m fine with a server choosing to interpret the request anyway it sees fit. [...] My concern is with clients coding with to the assumption as to...Excerpt from programming: what's new online at
Name one :)
A use case where a partial update is desirable? Here’s one you may have heard of. A number of resources (feeds, collections) may be partially updated based on that particular request.
I don’t like the way Joe explains the technique. What Joe describes as an unabashed “how to” is more appropriately (IMHO) described as two smaller steps. Partition your resources so that everything that needs to be independently updated has a separate URI, and recognize that a PUT need not be preceded by a GET.
There are a number of application issues that need to be worked out by combining these two, for example: how to handle resources that overlap, and how to handle the concurrency issues if the PUT is not preceded by a GET. For some applications, this may be an issue, for others not. Overall, that makes me uncomfortable with describing this in a post with a title of “how to” and closes with “So there you have it, outside of six open questions, a nice RESTful way to do partial updates.”. But that’s just me.
Posted by Sam Ruby atIt is possible; it’s possible to do for types other than Atom entries*; it’s possible to do within AtomPub; it’s possible to do it without a REST Fail. If I could get one non-working weekend, I’d knock up an ID.But such should be possible without violating the spec or spirit of either HTTP’s PUT or Atom’s entry.
Well, we’re halfway there already, and my post demonstrates that it is easily possible to take care of the other half. If you want some help on that I-D, let me know.
Posted by James Snell atgthank on Joe Gregorio: How To Do RESTful Partial Updates
Wasn’t that a [quote from Sam Ruby]([link])?...Excerpt from programming: what's new online at
Sam Ruby: Embrace, Extend then Innovate
[link] [comments]...Excerpt from programming: what's new online at
The XPath idea seems kind of interesting. You have <category term="foo" />, and call DELETE /path/to/item?element=//category[@term='foo'] (url encoded) to delete that element. Similarly POST to an element to append something (inside the selected element), PUT to overwrite the element.
But it does seem coupled. There’s no general way that I know of to say <category term="foo" me-href="?element=/category[0]" /> — a way of saying “this element lives at this location”. There’s some link tags, but you can’t really do that generally — you need to understand the format enough to figure out what enclosing tag the link is referring to, or if you just choose the most immediate parent then the format has to allow link tags. xml:base almost seems vaguely like this... but not.
Overall, that makes me uncomfortable with describing this in a post with a title of “how to”
Obviously, the correct solution is for Joe to rename the article with a question mark at the end, like they do on Fox News.
“How To Do RESTful Partial Updates ... ?”
Posted by Mark atThe XPath idea would eliminate some of my objections with resource-oriented architectures... you could expand it to update ALL resources under a certain logical hierarchy... like changing every copyright node in every document in your system:
PUT /path/all-items?element=//copyright
Or perhaps a modification of every document with a specific metadata signature... say change the ‘owner’ node for ‘Sue Jones’ to ‘Sue Smith’ after she gets married. That would ease the burden off of the end user of knowing exactly which resource they need to modify... which could be dangerous. You’d probably want to restrict that power to only trusted users.
It would also be cool to pass an XPath query in a GET to get a manifest (or the actual documents) of the results of the query.
Of course, then you’re limited to what XPath can express, and its context insensitivity... and if you try to do something fancy, I’d sense danger with all kinds of XPath injection attacks.
Still interesting tho...
Posted by bex atRESTful Partial Updates
Over on Sam’s blog, I see a little debate about Joe Gregorio’s How To Do RESTful Partial Updates. Sam is correct that Joe’s technique is not RESTful. I’ll explain why below, and present an alternative technique. I don’t...Excerpt from Open Rob Sayre's Open Mozilla Open Blog at
“A use case where a partial update is desirable? Here’s one you may have heard of. A number of resources (feeds, collections) may be partially updated based on that particular request.”
A member resource is just a resource. Updating the collection is an incidental thing. Hence we didn’t insist the state of the collection is sync’d with the state of the resource in AtomPub (cf the delete case). WebDAV did so at one point, and undid it later. Collections are never updated directly in AtomPub.
Posted by Bill de hÓra atThoughts on Google’s Proposal for Granular Updates in AtomPub
... [more]Trackback from Dare Obasanjo aka Carnage4Life at
POST and PATCH
It’s 7am, I’m sitting in the Auckland Koru Club on my way home and reading the minor kerfuffle regarding PATCH with interest. For me, the critical difference between PATCH......Excerpt from mnot’s Web log at
“Placing verbs in URIs definitely smells bad.”
My bad. Fixed. A while ago...
“Having some servers interpret the removal of elements (such as content) as a modification, and others interpret the requests in such a way that elided elements are to be left alone is hardly uniform or self-descriptive.”
Sorry, not following you, where are you seeing two different types of behavior?
Posted by Joe Gregorio atThe HTTP Sweet Spot
We seem to have pretty widespread consensus, these days, that HTTP, or perhaps the RESTful approach it exemplifies, offers a pretty sweet substrate for pushing and pulling data around at Web scale. We got further evidence this week when a bunch of...Excerpt from ongoing at
Sorry, not following you, where are you seeing two different types of behavior?
Deverbifying the URIs addresses this concern.
Posted by Sam Ruby atPartial Partial Update Update
Funny how ideas come back to life sometimes. I was noodling on a JSON blog-everything-format thingy in 2006-2007, and there’s the good idea, buried and badly formatted in Section 5.2. Lots of interesting PATCH follow-up, too. Mark Nottingham...Excerpt from Open Rob Sayre's Open Mozilla Open Blog at
Sam Ruby: Embrace, Extend then Innovate
Placing verbs in URIs definitely smells bad....Excerpt from del.icio.us/alan.dean at
PATCHes and Cream
It took several months, but we’re finally getting some really good discussions going about PATCH…. Rob Sayre 1 and 2 Roy Fielding Tim Bray Mark Nottingham Dare Obasanjo Sam Ruby 1 and 2 Joe Gregorio Aristotle Pagaltzis Update: Subbu Allamaraju For...Excerpt from snellspace.com at
POST and PATCH
(for comments by: Erik Mogensen, see this entry’s page .) It’s 7am, I’m sitting in the Auckland Koru Club on my way home and reading the minor kerfuffle regarding PATCH with interest. For me, the critical difference between PATCH and...Excerpt from WebService, SOA, ESB, what ever... at
I have always thought that it makes sense to;
a) use the base URI of the resource for the whole document
b) to refer to each element in the document resource by appending its XPath to the URI as additional path info
c) to use the HTTP verbs to modify individual elements just as one would modify the whole document - including delete
d) to only do one CRUD operatio per request
Posted by Vihung Marathe at
Interesting questions at the end there.
I remember when there was some buzz around Syncato ([link]), a product that enables the addressability of pieces of a document, rather than the whole document. I wonder if you could use that idea to shed some light on the last two questions - you send a DELETE request with the URI of the entry plus an XPath to the category.
Posted by roberthahn at