OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: A question about REST and transaction isolation

[ Lists Home | Date Index | Thread Index ]

From: 'ari@cogsci.ed.ac.uk@INTERNET@wtgw'(K. Ari Krupnikov)
> User A GETs a resource and edits it. User B GETs a resource and edits
> it. User A PUTs the modified resource back. User B PUTs her version of
> the modified resource back, unaware of A's edits. A's edits are lost
> without anyone noticing. What I want to happen is B to get a 409
> "Conflict" or some such.

This seems identical to the WebDAV use cases.
I'm not sure if it counts as REST, but I have built XML repositories for 
collaborative engineering that more or less appended the WebDAV method to the 
resource path (as there was no support for selecting different methods in the 
client), and use get or post depending on whether the resource is updated.

For a transactional service with prepended verbs, an additional verb 
'/working-copy/foo' that gets the working copy of the locked resource '/foo' would 
allow the temporary working copy to be got or put.  As the working copy can only 
exist once the resource is locked, and a resource may only be locked once, this 
resource is unique.

An example sequence of commands might be:

any-user GET   /foo              => the resource foo
any-user GET   /lock/foo         => the lock status of foo
user-A   POST  /aquire-lock/foo  => the lock status of foo having aquired a lock
user-A   GET   /working-copy/foo => the working copy of foo, initially the same as 
user-A   PUT   /working-copy/foo => updates working copy of foo
user-B   POST  /lock/foo         => error: foo locked by user-A
user-B   GET   /working-copy/foo => error: foo locked by user-A
any-user GET   /foo              => the previous version of the resource foo
user-A   POST  /commit/foo       => commits changes working copy of foo
any-user GET   /foo              => the modified resource foo
user-A   POST  /release-lock/foo => the lock status of foo having released the lock

> A lockfile is a document. Just not one I would have thought should be
> exposed to the user :=)

The lockfile was exposed to admins. Users were verified by digest authenitication, 
there was no need to bother with cookies or the like (this was for a secure 
intranet, so that was considered sufficient). 


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.


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

Copyright 2001 XML.org. This site is hosted by OASIS