JSON Patch – a format for describing changes to a JSON document

Post by azinman2 » Thu, Oct 30, 2014, 4:49 AM UTC

nacs wrote: post #52

function_seven wrote: post #30

Earlier quoted context omitted.

> Errr, to apply any delta, including these, you need the document on hand. If your goal is to store deltas, this is no better than anything else. Doesn't this allow the sender to send updates without knowledge of the existing values, though? With a string diff, the existing value would have to be known. > This is in no way better at handling concurrent changes than anything other diff format. In fact, the extra oper…

> Doesn't this allow the sender to send updates without knowledge of the existing values, though? This system requires knowledge of existing values/nodes to create the diff/patch document. However for JSON data, it does have the advantage of not clobbering data unlike a string diff as you mentioned.

Post by steveklabnik » Thu, Oct 30, 2014, 4:53 AM UTC

drderidder wrote: post #44

andrewstuart2 wrote: post #39

Earlier 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…

Hmm, I got the impression that REST purists insist on using PATCH. Rails 4 uses it for their REST implementation, for example. Also check out Will Durand's post [1]. I mused about the relative merits of PATCH vs POST in a blog post [2] - if you have any references you wouldn't mind leaving in the comments, I'd love to check them out. PS. nesting resources is a pretty interesting issue in itself; there seem to be a fe…

Post by hmbg » Thu, Oct 30, 2014, 6:10 AM UTC

DonHopkins wrote: post #47

jackhammer wrote: post #18

Earlier quoted context omitted.

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.

That's why you use a canonicalizing JSON serializer, which you'd also want to use if you were tracking changes to JSON in git, for example.

Post by skrebbel » Thu, Oct 30, 2014, 6:30 AM UTC

disordinary wrote: post #32

Having the paths in ever operation seems needlessly verbose. If I had an object { id name, password, email, phone } And I wanted to replace the email and phone items would I need to go: {"op": "replace", "path": "/user/0/email", "value": "new@email.address"} {"op": "replace", "path": "/user/0/phone", "value": "+64 4 555 5555"} If I have big objects then that is going to be allot of information to transport, something…

Post by jpierre » Thu, Oct 30, 2014, 7:03 AM UTC