Hacker News Reader

Comment by mahmoudimus | Hacker News Reader

The PATCH mechanisms seem like RPC to me. Having an operation that is passed in the payload, i.e. "replace", is awkward.

Why can't you just PATCH a resource?

    PATCH /resource

    {
        "src": "newvalue.png"
    }

View on HN

The `PATCH` mechanism is an HTTP verb (RFC 5789: http://tools.ietf.org/html/rfc5789) using a standard patching mechanism (RFC 6902: http://tools.ietf.org/html/rfc6902). Both are RFCs that seemed like good foundations to build on.

Ah, I hadn't heard of RFC6902. I'll give it a read.

I'm still of the opinion that it might be overkill to use only replace from that RFC when you can just PATCH the actual field to change.

Is there some bit of wisdom or experience that I'm missing?

The main reason was to unify patches to attributes with patches to relationships, which do require richer semantics.

It also makes it really easy to add a compound PATCH (updates to posts/1/title, posts/1/rels/author, posts/2/body, etc. all at the same time) in a single format. Once I bought into JSON Patch for the rest of this stuff, I figured I may as well use it for attributes :)

Interesting, how can I get more involved with how this is going to shape up?

You'll see me link to a repo soon with the text of this.

Here it is: https://github.com/json-api/json-api

It's hard to do key removal that way, you end up reasserting all of the other fields in that subdocument, whose values may have changed since your last retrieval.

There's also some value in the patch format looking somewhat different to the main format, to avoid confusion.

ah, key removal is indeed much easier this way.

The biggest advantage, though, is the same as any reason why you follow a standard: JSON-patch and the PATCH verb are understood by everyone, and so re-using them to take advantage of generality is better than inventing your own special take on updating JSON documents.

Reply on news.ycombinator.com