41–50 of 112 posts
The op missing is string diff. If a very long string value has changed, no matter how little the change is, you'll have to include the entire string in the patch.
We (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…
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.
that wouldn't foretell an optimistic future for this.
Earlier quoted context omitted.
I might misunderstand your comment but FWIW, buried in RFC 5789 the description of PATCH calls for a "description of changes" to be sent, so JSON Patch is trying to define a format for the set of changes to meet the requirement for using PATCH (and implementing REST) correctly. Still, JSON Patch is just too clunky compared to the elegant simplicity of JSON itself, IMHO.
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…
PS. nesting resources is a pretty interesting issue in itself; there seem to be a few different schools of thought about that, ie. using the '/' in URLs like the '.' scoping operator on objects, versus a flat scheme where all the different collections live at the topmost level, versus a combination of both or even using one as an alias for the other.
1. http://williamdurand.fr/2014/02/14/please-do-not-patch-like-...
2. http://51elliot.blogspot.ca/2014/05/rest-api-best-practices-...
In the example given the original text is 34 bytes long, the patch is 151 bytes, and the result is 42 bytes. Storing both the new text and the old text is 76 bytes which is about half of the size of the patch. If this were a corner case that rarely happened, then I wouldnt bring it up. However, it is actually a common case (and is even given as the example!) and has such terrible characteristics, there is no reason to use it.
Earlier quoted context omitted.
Can you explain why? This seems like a trivial application of any copy/add delta format, which are easily expressed in text diff format.
A simple example: if the order of the keys is different, say because of a different json implementation, semantically the document is identical, but you can't apply the patch anymore.
The op missing is string diff. If a very long string value has changed, no matter how little the change is, you'll have to include the entire string in the patch.
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 PA…
This proposal is more in line with the system you describe (except null instead of undefined). https://tools.ietf.org/html/rfc7386 I prefer it, and think it's much easier to understand.
1.http://51elliot.blogspot.ca/2014/05/rest-api-best-practices-...
The op missing is string diff. If a very long string value has changed, no matter how little the change is, you'll have to include the entire string in the patch.
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.