Comments on: REST, the Lost Update Problem, and the Sneakernet Test

By: Kyle Marvin

Kyle Marvin — Wed, 13 Jun 2007 23:40:02 +0000

For GData, the edit URL that contains the versioning info is actually contained within the resource (atom:entry/atomk:link@rel=”edit”). So it could be viewed as an implementation of the algorithm proposed here.

By: Dave Johnson: Latest links: do you Dare criticize the APP? | Server software

Mon, 11 Jun 2007 16:11:41 +0000

[...] David Megginson: REST, the lost update and the sneakernet test: - "Without exclusive locks, there’s no way to avoid this problem, but it is possible to detect it." [...]

By: Dare Obasanjo aka Carnage4Life - GData isn't a Best Practice Implementation of the Atom Publishing Protocol

Mon, 11 Jun 2007 02:01:26 +0000

[...] de hÓra: APP on the Web has failed: miserably, utterly, and completely David Megginson: REST, the Lost Update Problem, and the Sneakernet Test Bill de hÓra: Social networks, web publishing and strategy taxJames Snell: [...]

By: dan

dan — Mon, 11 Jun 2007 01:55:58 +0000

“SSE is ideal for bidirectional, asynchronous synchronization, particularly for scenarios where multiple people can independently edit or create entries–where there is not a single “master” copy of the data and each end user has their own copy of the data.”

http://msdn2.microsoft.com/en-us/xml/bb190613.aspx

By: david

david — Sun, 10 Jun 2007 12:15:10 +0000

Sjoerd: Most webapps still use HTML forms and POST, not PUT — since they repost the whole form (rather than just the changed fields), they run into exactly the same lost update problem. You’re right that you could hand-code something in JavaScript that uses etags with either POST or PUT and XMLHTTPRequest, as long as you’re working with a web browser that has JavaScript enabled, and not, say, a cell phone or similar; on the other hand, people are starting to write AJAX-y webapps that work offline, and it’s only a small step from that to full sneakernet compatibility.

I guess that this is just an extension of the very old protocols-vs-formats debate.

By: Sjoerd Visscher

Sjoerd Visscher — Sun, 10 Jun 2007 10:11:09 +0000

I don’t agree that using HTTP headers is a bad idea.

You have to write the eTag stuff anyway for caching GETs, so it would be easy to generalize the support to PUT as well.

As for browsers, the only way to do PUT in browsers is with XHR, which has full header support, so no browser changes are required.

So for webapps, which aren’t sneaker-compatible anyways, the w3c solution sounds perfect to me.

By: Aristotle Pagaltzis

Aristotle Pagaltzis — Sun, 10 Jun 2007 02:40:57 +0000

FWIW, you do locking in REST just like you do everything else: by modelling locks as resources. You POST to the lock manager to ask for a lock, and it creates a new lock resource and gives you the URI. What you do with that depends on a number of considerations; maybe the resource contains some sort of auth token, or a special URI to which to PUT your update, or maybe the lock resource itself accepts the update on behalf of the actual resource. Once you’re done, you DELETE the lock.

Couldn’t be much simpler.

By: david

david — Sun, 10 Jun 2007 02:10:46 +0000

In a JPEG file, you could stick in the version number as extended EXIF data, but I understand your point in general. On the other hand, not only is an etag not widely supported, but as I mentioned, the information gets lost unless the representation stays on a single system with an open connection to the server, which is severely limiting.

For binary objects being edited by non-browser clients, maybe the best thing would be to distribute them in some kind of package with a small, standard metadata file (XML or otherwise). The model of JAR files springs immediately to mind.

By: Pete Lacey

Pete Lacey — Sun, 10 Jun 2007 01:42:46 +0000

Some immediate problems I see with this scheme are:

1. What if the resource is a binary object, e.g. a JPEG file?
2. Putting this information in the message violates the self-descriptive REST constraint. One could argue that a version number _is_ part of the representation, and not metadata external to the representation and valuable to intermediaries. But keeping this information in the header as an ETag allows me to let off-the-shelf software worry about this for me. For instance, a Web server can manage the lost update problem on ordinary files. Though, admittedly, none do. So, it seems that “version” information really belongs in the headers.
3. Ideally, one should be transferring higher-order media-types, which may not be extensible. Or, if they are, requires that everyone agree on this versioning extension for every different media-type.

By: david

david — Sun, 10 Jun 2007 00:45:31 +0000

Thanks for that info, Han. I have no problem including the version number to retrieve a specific version of a resource from the history, e.g.

http://www.example.org/resource.xml?version=3

or even

http://www.example.org/resource/3/

but keeping the number in the URL for delete/update of the latest version fails the sneakernet test, as you point out.