Well you could send null to delete a field.
{ "foo": null }
Append, insert at, remove, and remove at are more ambiguous.
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?"
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.
Null != missing.
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, ...
{ "foo": null }
{ "foo": 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