Hacker News Reader

Hacker News

Comment by coolgoose | Hacker News Reader

Full thread

coolgoose

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.

View on HN

> 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.

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.

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.

Yep. Another common case is appending to an inner array vs replacing that array.

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

DELETE doesn't have to remove the entire resource, it's up to the receiving service on how to implement it.

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.

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.

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.

DELETE, per spec, does not take a body and any body it does have is ignored.

Well you could send null to delete a field. { "foo": null }

Append, insert at, remove, and remove at are more ambiguous.

And how do you set a field to null?

Same way.

as in `{null:null}` ?

won't that set a field called 'null', to the value null?

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.

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.

> 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, ...

So you set a field to `null` using

    { "foo": null }

and you delete a field using

    { "foo": null }

don't you see a bit of an issue there?

To delete something, I imagine you set it to undefined. I don't know anyone who uses the undefined state at rest for anything interesting.

JSON doesn't have undefined, only null

the partial updates approach works ok for updating 'schemaful' data, where it could only ever mean to set the field to null and could never delete the field from the object altogether

but for editing a JSON document or other schemaless data then both operations are possible and you'd need to be able to distinguish them

There are all kinds of solutions ("why not just use undefined instead?"), but whichever it is, a decision has to be made, documented, remembered, and edge cases decided. Whatever you have, now the API has a non-obvious custom spec just for that API alone. It's not a "why not just".

I guarantee, another dev would come along, look at the custom spec, and think "Why not just use JSON Patch?"

undefined would in theory be slightly "better" for deleting values (the value { key: undefined } serializes to {}), but, alas, it isn't supported by JSON, so you'd have to use a custom serializer and deserializer for it to even work.

I would expect in such cases that JSON Merge Patch, and its media type, would be used to head off bikeshedding discussions.

https://www.rfc-editor.org/rfc/rfc7396.html

This exists, and it is called JSON Merge Patch.

https://www.rfc-editor.org/rfc/rfc7396.html

Reply on news.ycombinator.com