4 ms·

This proposal is more in line with the system you describe (except null instead of undefined). https://tools.ietf.org/html/rfc7386 https://tools.ietf.org/html/r

by Dashron 12y ago

This proposal is more in line with the system you describe (except null instead of undefined). https://tools.ietf.org/html/rfc7386 https://tools.ietf.org/html/rfc7386 I prefer it, and think it's much easier to understand.

drderidder 12y ago
Oh, good - someone wrote an RFC for it - thanks for the link! It looks a lot like a post on partial updates in REST [1] where I recommended using null in the context of relational databases like mysql. Now I kinda feel undefined might be a better way to explicitly delete properties, especially if using a NoSQL database. 1.http://51elliot.blogspot.ca/2014/05/rest-api-best-practices-3-partial.html http://51elliot.blogspot.ca/2014/05/rest-api-best-practices-...
- logn 12y ago
  I think they used null for deletion because undefined isn't in the JSON spec. It's more of a Javascript standard.
  - drderidder 12y ago
    Thanks, you're right. "null" is what I do use - I forgot undefined won't work with JSON.parse. It would be nice to have a way to explicitly define a property as null, versus non-extant.
tiglionabbit 12y ago
I like it, but it's easy to get unintended results if you aren't careful. For example: https://gist.github.com/nickretallack/e0c17b338ee8bda2b67e https://gist.github.com/nickretallack/e0c17b338ee8bda2b67e If you start with original.json, then client 1 applies add-middle-name.json, and then moments later client 2 applies change-name.json not knowing that the other patch had been applied, you'll end up with a possibly unintentional merging of the two. I'm assuming change-name here wanted to clobber the whole name object, and did not intend to merge and keep the middle name. There's a couple ways around this. One is to code defensively and always pass the middle:null when clobbering the name, since you know other clients could set a middle name. The other is to do some sort of versioning check to ensure no one else has changed the document since you last fetched it. That could be implemented outside the json patch, using if-not-modified headers or something, though it is tempting to do it with the "test" actions provided in the main spec discussed here.

by Dashron 12y ago

drderidder 12y ago

Oh, good - someone wrote an RFC for it - thanks for the link! It looks a lot like a post on partial updates in REST [1] where I recommended using null in the context of relational databases like mysql. Now I kinda feel undefined might be a better way to explicitly delete properties, especially if using a NoSQL database. 1.http://51elliot.blogspot.ca/2014/05/rest-api-best-practices-3-partial.html http://51elliot.blogspot.ca/2014/05/rest-api-best-practices-...

logn 12y ago
I think they used null for deletion because undefined isn't in the JSON spec. It's more of a Javascript standard.
- drderidder 12y ago
  Thanks, you're right. "null" is what I do use - I forgot undefined won't work with JSON.parse. It would be nice to have a way to explicitly define a property as null, versus non-extant.

tiglionabbit 12y ago

I like it, but it's easy to get unintended results if you aren't careful. For example: https://gist.github.com/nickretallack/e0c17b338ee8bda2b67e https://gist.github.com/nickretallack/e0c17b338ee8bda2b67e If you start with original.json, then client 1 applies add-middle-name.json, and then moments later client 2 applies change-name.json not knowing that the other patch had been applied, you'll end up with a possibly unintentional merging of the two. I'm assuming change-name here wanted to clobber the whole name object, and did not intend to merge and keep the middle name. There's a couple ways around this. One is to code defensively and always pass the middle:null when clobbering the name, since you know other clients could set a middle name. The other is to do some sort of versioning check to ensure no one else has changed the document since you last fetched it. That could be implemented outside the json patch, using if-not-modified headers or something, though it is tempting to do it with the "test" actions provided in the main spec discussed here.