[
Lists Home |
Date Index |
Thread Index
]
Seairth Jacobs <seairth@seairth.com> writes:
> >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.
> >
> Take a look at the ETag (RFC2616 14.19)and If-Match (14.24). In the
> request, you would get back an ETag value (which might be the
> timestamp of the resource, some GUID, etc.) When PUTting the updated
> resource, you use If-Match. If the resource has been updated in the
> interim (and therefore has a new ETag), then you get back a 412
> "Precondition Failed" (10.4.13) response.
Interesting. I thought it was mainly intended for GET cache control,
but I guess it's as valid for updating methods.
I don't think it's going to work for me in this project, because we
want to support browser clients. But I'll definitively keep it in
mind.
Speaking of browsers, is there a good reason they only support GET and
POST? I mean the HTML DTD only has these two as legal values for the
method attribute on FORM, but is there a reason for that?
> >>REST isn't a good idea for isolating a transaction unless that
> >>transaction is expressed as a document.
> >>
> >
> >A lockfile is a document. Just not one I would have thought should be
> >exposed to the user :=)
> >
> I'm not sure that I would equate a "transaction resource" to a
> "lockfile document".
Like I said, probably a bad idea, but you could. A lockfile says who
(user or process) has an open transaction on a resource, when the
transaction started, sometimes whether it's a read or read-write lock,
etc.
Ari.
--
Elections only count as free and trials as fair if you can lose money
betting on the outcome.
|
