5 ms·
This spec has come up a couple times; the first time I wondered whether a simpler approach might be acceptable: * setting properties to be updated * omitti
by drderidder 12y ago
This spec has come up a couple times; the first time I wondered whether a simpler approach might be acceptable:
* setting properties to be updated
* omitting properties to be unchanged
* explicitly setting 'undefined' properties to be deleted
I've used that approach and github seems to have done something similar. I like the idea of a patch spec for JSON - it's required by a strict implementation of REST with HTTP PATCH - but the proposals I've seen so far seem just beyond the ken of the forehead-slapping simplicity that everyone loves about the JSON format and the parse & stringify methods.
- Dashron 12y agoThis 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 agoOh, 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 agoI think they used null for deletion because undefined isn't in the JSON spec. It's more of a Javascript standard.
- drderidder 12y agoThanks, 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 agoI 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.
- tracker1 12y agoMost serializers will omit undefined (I don't believe it's allowed as a JSON value. That said, I think null should be sufficient. Though, MongoDB already defines update syntax pretty well, and would just assume follow that syntax. http://docs.mongodb.org/manual/tutorial/modify-documents/ http://docs.mongodb.org/manual/tutorial/modify-documents/ It's not perfect, but it is pretty widely used, and well thought out enough for this purpose.
- almost 12y agoThis is what people often do apart from the last point (no undefined in JSON, and by definition anything you could choose here would conflict with valid values). This works well for a lot of use cases but can't express everything you might want to do with something like JSON-Patch.
- almost 12y agoThis is what people often do apart from the last point (no undefined in JSON, and by definition anything you could choose here would conflict with valid values). This works well for a lot of use cases but can't express everything you might want to do with something like JSON-Patch.
- knightofmars 12y agoYES! I couldn't agree more. Thank you for making this comment, specifically this part, "...the proposals I've seen so far seem just beyond the ken of the forehead-slapping simplicity...". To me the existing proposals are a complete aberration when viewed along with the rest of the JSON spec and standard REST implementations. I'm really happy to see that GitHub took the simpler more intuitive implementation as well.
- _betty_ 12y agoConsidering how basic this is you wouldn't even really need a standard. jQuery basically already has support for this exact thing, and it's only a few lines of pure JS. $.extend({a:'b', b:2, c: [1,2]}, { a: null, b: 0})
- _betty_ 12y agoOf course it'd be hard to insert an item into that array...