PATCH and resource versioning

[b]

How does JSON API handle or indicate conflicts when multiple clients simultaneously attempt to modify a resource?

[steveklabnik]

I'm mobile, but the PATCH RFC should have this defined, no?
—
Sent from Mailbox for iPhone

On Mon, May 6, 2013 at 5:45 PM, Benjamin Black notifications@github.com
wrote:

How does JSON API handle or indicate conflicts when multiple clients simultaneously attempt to modify a resource?

Reply to this email directly or view it on GitHub:
#41

[mamund]

use ETag for handling update conflicts (http://www.w3.org/1999/04/Editing/).

[b]

Dandy. Spec needs to include this behavior as a MUST or conflicts will produce undefined and unpredictable results. That would be surprising. Minimize surprise.

[SebastianEdwards]

+1 for requiring an If-Match header on requests where conflicts can occur.

[steveklabnik]

Yup. Using ETags is a Good Idea.

Section 2.2 of the patch rfc ( http://tools.ietf.org/html/rfc5789 ) says

   Conflicting state:  Can be specified with a 409 (Conflict) status
      code when the request cannot be applied given the state of the
      resource.  For example, if the client attempted to apply a
      structural modification and the structures assumed to exist did
      not exist (with XML, a patch might specify changing element 'foo'
      to element 'bar' but element 'foo' might not exist).

Also seems good.

[sandstrom]

Is there a particular reason this issue was closed? Has it been moved or otherwise solved?

I just opened an issue in rails-api/active_model_serializers#532 and thought I'd probe for interest here too.

[steveklabnik]

Has it been moved or otherwise solved?

Yes, use etags and 409 Conflict.

[sandstrom]

I'm sure you (and others) have thought of this already, and decided it's outside the scope of json-api. But my thought was that one could standardize a key to use for these tags as well as the associated behavior.

[steveklabnik]

We can't guarantee that any particular item has any particular key, since we only even name one or two, and they're optional. And I'm not sure that we need any additional behavior other than what's in the standard already.

That said, we'd entertain an actual proposal, if you want to give it some thought and make a PR. I'm not perfect. :)

[b]

_etags field when multiple items are returned seems a useful thing to
standardize, imo.

On Fri, Mar 28, 2014 at 12:00 PM, Steve Klabnik notifications@github.comwrote:

We can't guarantee that any particular item has any particular key, since
we only even name one or two, and they're optional. And I'm not sure that
we need any additional behavior other than what's in the standard already.

That said, we'd entertain an actual proposal, if you want to give it some
thought and make a PR.

Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-38956063
.