Re: REST: ETag handling

Hi Ralf:

In message <[email protected]>,
Ralf Schlatterbeck writes:
>The current REST-API code uses ETag to prevent concurrent modifications.
>I noticed that the ETag header has the etag in double quotes, i.e.
>ETag: "....."
>So naive usage of the header with
>etag = r.header['ETag']
>will fail because the resulting value includes quotes. The @etag value
>in the json representation does *not* include quotes.

Maybe it should be: { "@etag": ""etagvalue"", ... } I am not sure how to
encode " inside a json value but you get the idea.

>I think the quotes should be removed in the header, too.

I thought the quotes in the header were required by spec.
See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

>Another question regarding ETag: The 'PUT' method is supposed to be
>idempotent. Requiring an ETag kills this property: A second equivalent
>PUT request where the change is already applied will fail because the
>ETag doesn't match. Shouldn't we optionally allow a PUT without an ETag
>and document that using an ETag will make the method non-idempotent?

Well we can't remove etag as that is required to avoid clobbering an
update.  Consider the following:

  app1 gets issue/27
  app2 gets issue/27
  app2 changes status to open from new
  app2 puts change
  app1 changes status to close from new
  app1 puts change

app1 made a change to issue27 that was not based on the current data.
This change should not have been accepted any more than a post in the
web interface where the value of the field had been changed. The web
interface detects a collision and raises an error letting the user
resolve the conflict..

Regarding idempotentcy. I read that as: if the preconditions of the put
are met, multiple applications of the same PUT data should not change
the state of the resource.

etag is a precondition. It is not part of the representation although
it is derived from the representation.  There is no requirement that
multiple PUTs with the same data have to be accepted. Idempotency only
requires that if the PUT returns 200, the state of the resource has
not changed.

This is true. If you do a get on a resource and put the same data as
the GET multiple times, you will end up with the same representation
every time. The return json blob will show no updated fields. In fact
in this case the ETag will even stay the same.

Does this make sense?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.