|K. Ari Krupnikov||Feb 8, 2004 4:59 pm|
|David Megginson||Feb 8, 2004 5:42 pm|
|K. Ari Krupnikov||Feb 8, 2004 8:58 pm|
|Seairth Jacobs||Feb 9, 2004 5:45 am|
|Seairth Jacobs||Feb 9, 2004 5:51 am|
|David Megginson||Feb 9, 2004 6:21 am|
|Bullard, Claude L (Len)||Feb 9, 2004 7:07 am|
|Bullard, Claude L (Len)||Feb 9, 2004 7:43 am|
|David Megginson||Feb 9, 2004 8:19 am|
|Bullard, Claude L (Len)||Feb 9, 2004 8:26 am|
|K. Ari Krupnikov||Feb 9, 2004 11:35 am|
|K. Ari Krupnikov||Feb 9, 2004 1:00 pm|
|Bullard, Claude L (Len)||Feb 9, 2004 1:45 pm|
|K. Ari Krupnikov||Feb 9, 2004 2:43 pm|
|Bullard, Claude L (Len)||Feb 9, 2004 2:51 pm|
|Jim Ancona||Feb 9, 2004 3:04 pm|
|David Megginson||Feb 9, 2004 4:46 pm|
|Seairth Jacobs||Feb 9, 2004 6:24 pm|
|K. Ari Krupnikov||Feb 10, 2004 9:54 pm|
|K. Ari Krupnikov||Feb 10, 2004 10:13 pm|
|Pete Kirkham||Feb 11, 2004 2:26 am|
|Julian Reschke||Feb 11, 2004 2:54 am|
|Klotz, Leigh||Feb 11, 2004 10:18 am|
|Robin Berjon||Feb 11, 2004 10:21 am|
|Chiusano Joseph||Feb 26, 2004 6:18 am|
|Michael Champion||Feb 26, 2004 7:29 am|
|Bullard, Claude L (Len)||Feb 26, 2004 7:51 am|
|Subject:||Re: [xml-dev] A question about REST and transaction isolation|
|From:||K. Ari Krupnikov (ar...@cogsci.ed.ac.uk)|
|Date:||Feb 10, 2004 10:13:52 pm|
David Megginson <dmeg...@attglobal.net> writes:
I'm not sure how well REST provides answers to the problem of moving resources around. Your problem is that the server, user A, and user B all have copies of the same information, and the server has to decide whether to accept or reject user B's version after user A has already done a checkin.
One easy solution is to add a sequence number or checkout date to each XML document:
This is not much different from adding transaction-id parameter to the request as I suggested originally, is it? There is no intrinsic reason to only support application/xml in PUT/POST; in this project, we need to support multipart/form-data as well to accept input from browsers. So your <pilot-record seq="123"> becomes pilot-record/Ari%20Krupnikov?seq=123&...
Of course, it is easy for the client to cheat by simply bumping up the sequence number and resubmitting, but then again, the client can arbitrarily change information anyway -- it's just a matter of letting people know when there might be a conflict.
Right. We all know this situation from CVS, either done it to someone or had this done to us, a "hostile check-in", so to speak.
As far as REST goes, the URL on the server always points to the server's current version of the information (the last checkin it accepted) -- that's about it.
Well, pilot-record/Ari%20Krupnikov points to the current version. pilot-record/Ari%20Krupnikov?seq=123 may well point to an archive version or to an uncommitted temporary version, possibly only available to the user who created it.
Speaking of which, is it reasonable wrt REST to allow or deny access to a resource based not simply on user+passwd but on user+passwd+query-string?
-- Elections only count as free and trials as fair if you can lose money betting on the outcome.