4 ms·

It is a really verbose spec. Why not just send partial fields and handle it server side? Not to mention its more data over the wire for small changes.

rendall 4y ago
> Why not just send partial fields...? You have: { "baz": "qux", "foo": "bar" } Then you send the patch: { "baz": "boo" } It's clear you want to change baz value to boo, but did you mean to delete foo or just ignore it? If "ignore", how do you indicate delete? If "delete", you will now have to send the entire JSON every time, anyway, so it's not a patch. Whatever your answers, there, it's not a "why not just..." situation. You have a deeply nested property in a gigantic JSON document that you want to move, "why not just" send { "op": "move", "from": "/a/b/c/d", "path": "/a/b/c/e/f" } To be clear, I have never seen JSON Patch before, either.
- gregorty 4y ago
  Sending it with different HTTP verbs might do the trick. For your example: { "baz": "boo" } DELETE would remove baz, PATCH would change baz, and PUT would, in effect, remove foo.
  - fortylove 4y ago
    What if you want to delete one attribute, and update another, within the same request? Seems like utilizing HTTP DELETE would not work well for this, unless you can specify it at the attribute level, leading you back towards something like JSON Patch.
    - ratww 4y ago
      Yep. Another common case is appending to an inner array vs replacing that array.
  - toomim 4y ago
    That doesn't work, because DELETE is defined to delete the entire resource. PUT is defined to replace the resource with the body, which would replace the resource with the patch. Only PATCH is defined to accept a patch and do something special with it. Another option, though, is to use the Range-Patch spec from: https://github.com/braid-org/braid-spec https://github.com/braid-org/braid-spec
    - gregorty 4y ago
      DELETE doesn't have to remove the entire resource, it's up to the receiving service on how to implement it.
      - actually_a_dog 4y ago
        Exactly. I have issues with this approach, but "DELETE is defined to..." is not one of them. DELETE does whatever the fuck you want it to.
        Sharparam 4y ago
        Abusing HTTP methods like this is something ElasticSearch does on some of their APIs. This is annoying because spec-compliant tools don't always play nice with them. For example: ElasticSearch can take a body on some GET requests, but many tools will not let you do this because a GET request should not have a body.
        toomim 4y ago
        If you have a proxy, cache, or middlebox in your network, and you use DELETE to mean "remove this key from the JSON object" your proxy won't know that, and will happily delete the entire resource, and tell everyone else that the resource has been deleted, and then your data will disappear, and that's not very fun.
  - deleted 4y ago
    [deleted]
  - dragonwriter 4y ago
    DELETE, per spec, does not take a body and any body it does have is ignored.
- jayd16 4y ago
  Well you could send null to delete a field. { "foo": null } Append, insert at, remove, and remove at are more ambiguous.
  - masklinn 4y ago
    And how do you set a field to null?
    - jayd16 4y ago
      Same way.
      - chii 4y ago
        as in `{null:null}` ? won't that set a field called 'null', to the value null?
        jayd16 4y ago
        As in { "foo" : null } You can interpret a null field the same as a missing field. You only need to worry if you have arbitrary dictionary keys and need to differentiate a null value from an missing key.
        rrrhys 4y ago
        Null could imply the field was present and a value not entered or not necessary. Missing could imply the field was never known about at all. The context is important. Null != missing.
        masklinn 4y ago
        > You can interpret a null field the same as a missing field. Not in the general case no, they are two different states, which may have entirely different semantics. For instance a missing field can mean "don't touch this field" while a field set to null means "set this field to null". Some schemas might opt to ignore this distinction and collapse the states, but that is a specific decision, and an express loss of information. > You only need to worry if you have arbitrary dictionary keys and need to differentiate a null value from an missing key. There are other situations where that's an issue, like the above, or when you're using the object as a set (which JSON doesn't have), or when you've defined the schema to never have missing fields (but possibly have some set to `null`) so clients will break, ...
crabmusket 4y ago
This exists, and it is called JSON Merge Patch. https://www.rfc-editor.org/rfc/rfc7396.html https://www.rfc-editor.org/rfc/rfc7396.html

rendall 4y ago

> Why not just send partial fields...? You have: { "baz": "qux", "foo": "bar" } Then you send the patch: { "baz": "boo" } It's clear you want to change baz value to boo, but did you mean to delete foo or just ignore it? If "ignore", how do you indicate delete? If "delete", you will now have to send the entire JSON every time, anyway, so it's not a patch. Whatever your answers, there, it's not a "why not just..." situation. You have a deeply nested property in a gigantic JSON document that you want to move, "why not just" send { "op": "move", "from": "/a/b/c/d", "path": "/a/b/c/e/f" } To be clear, I have never seen JSON Patch before, either.

gregorty 4y ago
Sending it with different HTTP verbs might do the trick. For your example: { "baz": "boo" } DELETE would remove baz, PATCH would change baz, and PUT would, in effect, remove foo.
- fortylove 4y ago
  What if you want to delete one attribute, and update another, within the same request? Seems like utilizing HTTP DELETE would not work well for this, unless you can specify it at the attribute level, leading you back towards something like JSON Patch.
  - ratww 4y ago
    Yep. Another common case is appending to an inner array vs replacing that array.
- toomim 4y ago
  That doesn't work, because DELETE is defined to delete the entire resource. PUT is defined to replace the resource with the body, which would replace the resource with the patch. Only PATCH is defined to accept a patch and do something special with it. Another option, though, is to use the Range-Patch spec from: https://github.com/braid-org/braid-spec https://github.com/braid-org/braid-spec
  - gregorty 4y ago
    DELETE doesn't have to remove the entire resource, it's up to the receiving service on how to implement it.
    - actually_a_dog 4y ago
      Exactly. I have issues with this approach, but "DELETE is defined to..." is not one of them. DELETE does whatever the fuck you want it to.
      - Sharparam 4y ago
        Abusing HTTP methods like this is something ElasticSearch does on some of their APIs. This is annoying because spec-compliant tools don't always play nice with them. For example: ElasticSearch can take a body on some GET requests, but many tools will not let you do this because a GET request should not have a body.
      - toomim 4y ago
        If you have a proxy, cache, or middlebox in your network, and you use DELETE to mean "remove this key from the JSON object" your proxy won't know that, and will happily delete the entire resource, and tell everyone else that the resource has been deleted, and then your data will disappear, and that's not very fun.
- deleted 4y ago
  [deleted]
- dragonwriter 4y ago
  DELETE, per spec, does not take a body and any body it does have is ignored.
jayd16 4y ago
Well you could send null to delete a field. { "foo": null } Append, insert at, remove, and remove at are more ambiguous.
- masklinn 4y ago
  And how do you set a field to null?
  - jayd16 4y ago
    Same way.
    - chii 4y ago
      as in `{null:null}` ? won't that set a field called 'null', to the value null?
      - jayd16 4y ago
        As in { "foo" : null } You can interpret a null field the same as a missing field. You only need to worry if you have arbitrary dictionary keys and need to differentiate a null value from an missing key.
        rrrhys 4y ago
        Null could imply the field was present and a value not entered or not necessary. Missing could imply the field was never known about at all. The context is important. Null != missing.
        masklinn 4y ago
        > You can interpret a null field the same as a missing field. Not in the general case no, they are two different states, which may have entirely different semantics. For instance a missing field can mean "don't touch this field" while a field set to null means "set this field to null". Some schemas might opt to ignore this distinction and collapse the states, but that is a specific decision, and an express loss of information. > You only need to worry if you have arbitrary dictionary keys and need to differentiate a null value from an missing key. There are other situations where that's an issue, like the above, or when you're using the object as a set (which JSON doesn't have), or when you've defined the schema to never have missing fields (but possibly have some set to `null`) so clients will break, ...

crabmusket 4y ago

This exists, and it is called JSON Merge Patch. https://www.rfc-editor.org/rfc/rfc7396.html https://www.rfc-editor.org/rfc/rfc7396.html