31–40 of 112 posts
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…
{
id
name,
password,
email,
phone
}
{"op": "replace", "path": "/user/0/email", "value": "new@email.address"}
{"op": "replace", "path": "/user/0/phone", "value": "+64 4 555 5555"} {"op": "rplc", "pth": "/user/0/", "ptc":
{ "email": "new@email.address", "phone": "+64 4 555 5555"}
}The thing you're competing against in terms of performance and efficiency is: 1. JSON.stringify() 2. Diff-match-patch: https://code.google.com/p/google-diff-match-patch/ 3. JSON.parse() There are several short-comings to the above approach though, specifically, you have to explicitly trade off performance vs. efficiency depending on the JSON you're dealing with. JSON Patch is going to give you a consistent performanc…
JSON data is not always stored as texts.
Or are you simply talking about javascript style object literals?
* setting properties to be updated
* omitting properties to be unchanged
* explicitly setting 'undefined' properties to be deleted
Seems like a good starting point, but it's a bit too simplistic for my taste. "Add" seems like it's not idempotent as the existing value seems to change what it does. Seems like a mistake to bundle array operations into "add" and "remove". Array indexing is going to be useless for most applications because it makes assumptions about what's already there, and there is no way to specify fine-grained preconditions (or r…
Surely supporting "increment"/"decrement" would break idempotency?
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…
var x = { a: 1, b: 'B', c: { x: "X", y: "Y", z: "Z" }, d: [{p:"P"},{q:"Q"},{r:"R"}] };
["d", 1, "q"].reduce(function (prev, curr) { return prev[curr]; }, x);
>>> "Q"
Earlier quoted context omitted.
I think you're missing the point. If I want to patch just one node and don't care what the rest of the document is, I cannot just use a text diff.
Can you explain why? This seems like a trivial application of any copy/add delta format, which are easily expressed in text diff format.
As long as they don't try to call it RESTful I think it's a good idea. On the other hand, if HTTP/2 can minimize the overhead of just making many consecutive HTTP calls, that feels a lot better to me than using what is essentially a constrained RPC interface.
As long as they don't try to call it RESTful I think it's a good idea. On the other hand, if HTTP/2 can minimize the overhead of just making many consecutive HTTP calls, that feels a lot better to me than using what is essentially a constrained RPC interface.
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 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 reflect a small change in that resource.
Perhaps the more elegant solution is to forget PATCH and use more nested resource identifier semantics (never thought I'd say that) so that you can appropriately identify the entire subset of the resource being altered.
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…
I prefer it, and think it's much easier to understand.