Re: PaceURINomenclature and PaceOnlyMemberURI

On 8/18/06, Elias Torres <elias-teabWVY4yyH1P9xLtpHBDw@xxxxxxxxxxxxxxxx> wrote:
> Kyle Marvin wrote:
> > On 8/18/06, Elias Torres <elias-teabWVY4yyH1P9xLtpHBDw@xxxxxxxxxxxxxxxx> 
> wrote:
> >>
> >> I think they are both easy to implement but I lean towards
> >> PaceURINomenclature because it gives me the option of separating my
> >> edit-uri from self-uri.
> >
> > For the record, POMU doesn't prevent you from splitting them... in
> > fact it says *nothing* about the self URI.
> >
>
> Hmmm.. That's a good point of view. Is the definition of 'self' in an
> earlier today that it must the full Atom representation of the entry
> correct? If so, wouldn't that say that client developers can always use
> it as a fallback mechanism *if* the member URI returns 409 let's say?

I think the intention would be that you do another GET on the Member
URI to get the current representation (that your PUT conflicted with)
and try to locally resolve the differences.  This is especially
important if using ETags, because you need the ETag value (from that
GET) for the matching in the PUT to have a chance to succeed and avoid
any lost updates.

In the case of GData, we actually return the current (server)
representation in the 409 response entity body, but I'm not sure I'd
recommend that generally.   For an ETags-based server, this isn't
useful  (beyond logging) because you'd have the current resource rep
but not its ETag.