4 ms·

The `PATCH` mechanism is an HTTP verb (RFC 5789: http://tools.ietf.org/html/rfc5789 http://tools.ietf.org/html/rfc5789) using a standard patching mechanism (RFC

by wycats 13y ago

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

mahmoudimus 13y ago
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?
- wycats 13y ago
  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 :)
  - mahmoudimus 13y ago
    Interesting, how can I get more involved with how this is going to shape up?
    - steveklabnik 13y ago
      You'll see me link to a repo soon with the text of this.
    - steveklabnik 13y ago
      Here it is: https://github.com/json-api/json-api https://github.com/json-api/json-api
- CiaranMcNulty 13y ago
  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.
  - mahmoudimus 13y ago
    ah, key removal is indeed much easier this way.
    - steveklabnik 13y ago
      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.

by wycats 13y ago

mahmoudimus 13y ago

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?

wycats 13y ago
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 :)
- mahmoudimus 13y ago
  Interesting, how can I get more involved with how this is going to shape up?
  - steveklabnik 13y ago
    You'll see me link to a repo soon with the text of this.
  - steveklabnik 13y ago
    Here it is: https://github.com/json-api/json-api https://github.com/json-api/json-api
CiaranMcNulty 13y ago
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.
- mahmoudimus 13y ago
  ah, key removal is indeed much easier this way.
  - steveklabnik 13y ago
    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.