{
         "baz": "boo"
      }

Another option, though, is to use the Range-Patch spec from: https://github.com/braid-org/braid-spec

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.

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

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

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

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

    { "foo": null }

    { "foo": null }

won't that set a field called 'null', to the value 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.

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

Null != missing.