2006/5/9, Toru Marumoto <[EMAIL PROTECTED]>:
What about updates?
Corrent spec 08 says,
{{
5.3.2 Updating a Resource
"Upon a successful update of the resource the server
responds with a status code of 200."
}}
how about adding,
"On successful updating, the response to the
PUT request MUST return a Location: header with
the URI of an Atom Entry Document representing
the updated resource."
some where.
Uh! you already know that URI!
Why would you need it there?
Has it something to do with GData's optimistic concurrency mechanism?
(I guess it does but I haven't started playing with GData so I'm a bit
ignorant about it…)
Couldn't it be solved in some other way? I mean, why would the URI of
the resource change? I understand the "need" for version -specific
URIs, but why couldn't there be a "latest version" URI? Clients should
then "GET" that entry using preconditions (If-Modified-Since,
If-None-Match, Cache-Control: no-cache, etc.) to be sure they have the
latest version. Servers could eventually also return it as part of the
200 (OK) response body (clients compare the atom:id to know whether
it's a "status message" or an updates version of the entry they're
editing; Content-Location doesn't really help here). This is how HTTP
is supposed to work I suppose.
plus,
"Since a client already know the atom:id, etc, the
server MAY return the body. But it SHOULD return
if any of associated mediea resource or edit or
edit-resource uri has been changed."
As I'm -1 on the SHOULD for the response body of 201 (Created)
responses, I'm also -1 on this one.
I'd be OK to invite server implementers to return the Atom Entry as
the response body (with any metadata needed to tell clients the Atom
Entry is the one they're editing/creating; I mean Location ==
Content-Location on 201 responses) so clients won't have to issue a
subsequent GET, but that's an optimization trick (both on the client
and server ends) and has *nothing* to do with interop: everything
works OK if you don't return the Atom Entry in the response body,
clients just have to do an additional request (hey, does anybody
remember last summer/fall? there were debates on batch updates et al.
and consensus were that 1) an additional request shouldn't be a
problem or at least should lead to preemptive optimizations, 2) it was
only optimization and 3) it could be adressed later)
So please:
1) don't try to optimize too early
2) let implementations sort it out (servers can return an Atom Entry
with Location == Content-Location in 201 responses to POST requests,
clients can compare atom:id in 200 responses to PUT requests)
3) eventually suggest optimization tips and tricks, but not dictate
them with SHOULDs or MUSTs (such as "if the response body is an Atom
Entry, then it MUST be the one that has been created/updated": there
are other means which cost almost nothing)
--
Thomas Broyer
