Is Choco Leibniz similar to Digestive? Better?
JSON Patch – a format for describing changes to a JSON document
81–90 of 112 posts
Re: JSON Patch – a format for describing changes to a JSON document
#82We (Empirical) have implemented a similar couple years ago in our json-backed model. I see two big problems with this standard: 1. Why express paths as a string if you have the ability to encode it as an array in json? Otherwise you run up against the escaping problem for which they use ~0 and ~1 (of all things?!) which is only going to cause bugs. 2. Indexing into arrays is a problem in distributed computing because…
While the escaping issues you mention are super nasty, those are from the JSON Pointer specification, which JSON Patch merely uses.
Re: JSON Patch – a format for describing changes to a JSON document
#83We (Empirical) have implemented a similar couple years ago in our json-backed model. I see two big problems with this standard: 1. Why express paths as a string if you have the ability to encode it as an array in json? Otherwise you run up against the escaping problem for which they use ~0 and ~1 (of all things?!) which is only going to cause bugs. 2. Indexing into arrays is a problem in distributed computing because…
Isn't a path just a slash-delimited array? To me, it's more readable as a path since we all deal with those everyday in our address bar. The machine can make it an array if it wants, but I'd prefer to see it in one line. I do wish they'd gone with backslash as an escape character. Don't know what possessed them to pull ~0 and ~1 out of their butts.
The problem with backslash is that it's already used by the JSON parser. If you happened to have a key `\/`, that would need to be written "\\\\\\/".
Re: JSON Patch – a format for describing changes to a JSON document
#84I've implemented an API against this and think it's pretty good.
http://microcosm-cc.github.io/#conversations-single-patch
We didn't implement the entirety of the standard as our resources are fairly small and simple and it would have been overkill.
The scenario we had is that we needed to take a set of changes to a resource, but parts of the JSON document are permissioned differently. i.e. You might have permission to change the document body, but not some audit trail meta data returned as part of the resource.
Treating patches as a batch of operations to be performed on a document (usually within one transaction) is a good way to do the processing for this scenario.
I know that there are other approaches, such as calculating a diff and just sending that... but describing operations does make the system less fragile and does make it easier for scenarios like the one we had where you could not assume that the entire resource is under a single permission structure.
Re: JSON Patch – a format for describing changes to a JSON document
#85Earlier quoted context omitted.
If you have strings that long, maybe it would be wise to break it up semantically into some collection of resources (paragraphs, lines, etc.). It could be reassembled as needed for display but then stored and updated as its semantic parts.
Taken to an extreme (and isn't that what programming is all about), that could end up using a lot more memory and overhead, storing an array of many short strings, instead of storing one big flat string. And it would also require more work and pointless code complexity to deal with many short strings.
As opposed to the pointless complexity that comes from implementing support for string diffs?
Having implemented a json differ (which is similar, but with different representations of the paths due to having uniform access to nodes in the tree due to having id elements everywhere that matters), I would consider string diffs overengineering.
Re: JSON Patch – a format for describing changes to a JSON document
#86Earlier quoted context omitted.
JSON data is not always stored as texts.
How else would you store it? Javascript Object Notation is text. Other formats such as BSON are different. Or are you simply talking about javascript style object literals?
JSON is external representation of objects. You can store the actual data on server in any form you like. Doesn't mean you have to store them in text.
Re: JSON Patch – a format for describing changes to a JSON document
#87Earlier quoted context omitted.
Isn't a path just a slash-delimited array? To me, it's more readable as a path since we all deal with those everyday in our address bar. The machine can make it an array if it wants, but I'd prefer to see it in one line. I do wish they'd gone with backslash as an escape character. Don't know what possessed them to pull ~0 and ~1 out of their butts.
The problem with backslash is that it's already used by the JSON parser. If you happened to have a key `\/`, that would need to be written "\\\\\\/".
That kind of inflation is just a side effect of format encapsulation. You're representing a path format inside the JSON format, both of which need to escape their delimiters if they're to be taken literally. I still think a single consistent escape character is cleanest.
The same argument applies when I have any defined escape character or delimiter that I want to use as a literal.
I'll admit it's less human readable if you have a key `\/` but I can't think of many good reasons you'd want that as a key, which is what makes them good escape characters and delimiters.
Re: JSON Patch – a format for describing changes to a JSON document
#88This 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 PA…
YES! 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.
Re: JSON Patch – a format for describing changes to a JSON document
#89Earlier quoted context omitted.
I definitely agree that it's a bit too clunky. I think it's arguable though that PATCH itself isn't quite RESTful as it doesn't describe the state of a resource at the identifier, but instead some subset of the state of that resource. Doing that kind of destroys the semantics of the resource identifier. You'd probably still find me arguing for PATCH as it's obviously preferable not to resend an entire resource to ref…
I think it's arguable though that PATCH itself isn't quite RESTful as it doesn't describe the state of a resource at the identifier, but instead some subset of the state of that resource. Doing that kind of destroys the semantics of the resource identifier. Can you expand on that point? I'm not clear on how would it affect the semantics of the resource identifier.
The resource identifier should uniquely identify the resource being described by the representation. PATCH literally means "Use the resource at this URI, but apply the enclosed state representation to some subset of that resource."
In that way, the state representation being sent only actually represents a subset of the resource being identified. I'd argue that this semantically makes the actual target of the new state a resource in itself and it should have its own identifier.
Re: JSON Patch – a format for describing changes to a JSON document
#90Earlier quoted context omitted.
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-...
I think they used null for deletion because undefined isn't in the JSON spec. It's more of a Javascript standard.
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.