It’s just data

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?


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

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 at

cgrand 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 at

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.

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 at

gthank 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.

Posted by Ian Bicking at

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 at

The 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 at

RESTful 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 at

WRT XPaths for editing: see XCAP - [link]

Posted by anonymous at

Thoughts 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 at

The 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 at

I think the paragraph about categories has more interesting questions.

Posted by Robert Sayre at

Partial 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

“Embrace, Extend then Innovate”

[link]

Posted by Bill de hÓra 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

“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. [...] My concern is with clients coding with to the assumption as to how the server works.  That’s called coupling.”

I agree. But how does HTTP PATCH address this at all? What is the difference between using a “patch document” against a HTTP PUT or HTTP PATCH? The important point seems to be that the document should explicitly indicate whether elided elements should be modified or left alone, but why couldn’t you mandate that the HTTP PUT format always be a patch document?

Posted by Gili at

How to submit RESTful partial updates?

Sam Ruby, author of “RESTful Web Services” seems to come out against the use of HTTP PUT for partial updates: [link] What isn’t clear is how partial updates should take place. As I...

Excerpt from How to submit RESTful partial updates? - Stack Overflow at

REST Partial Updates: Use POST, PUT or PATCH?

A couple of articles I have read recently are debating different options for partially updating a resource when you do not want to change or pass the whole thing. Take, for example this use case for a The Knot Checklist checklist: a vast majority...

Excerpt from Jason Sirota is ... at

gthank on Joe Gregorio: How To Do RESTful Partial Updates

Wasn’t that a [quote from Sam Ruby]([link])?...

Excerpt from reddit: the front page of the internet at

Partial RESTful update url structure

Lets say I have a User object /Users/1 . On my view, I have multiple partitions to edit this user, for eg. Information , Contact , Location . Which are in 3 seperate forms. Im thinking about doing: POST /Users/1?Part=Information , POST...

Excerpt from Partial RESTful update url structure - Stack Overflow at

Add your comment