Loading ...
Sorry, an error occurred while loading the content.

JSON Patch

Expand Messages
  • Paul C. Bryan
    I ve published an informational Internet-Draft for JSON Patch, a proposed structure for specifying partial modifications to JSON documents. You can see it at:
    Message 1 of 3 , Apr 23, 2011
    • 0 Attachment
      I've published an informational Internet-Draft for JSON Patch, a
      proposed structure for specifying partial modifications to JSON
      documents. You can see it at:

      http://tools.ietf.org/html/draft-pbryan-json-patch-00

      One of the primary motivations is to have a media type that can be used
      with HTTP PATCH (RFC 5789).

      Any feedback would be most appreciated.

      Paul


      [Non-text portions of this message have been removed]
    • Paul C. Bryan
      On Sun, 2011-04-24 at 18:37 -0600, Kris Zyp wrote (in response to an ... Point taken. In an iteration prior to publishing draft 00, I actually had a replace
      Message 2 of 3 , Apr 25, 2011
      • 0 Attachment
        On Sun, 2011-04-24 at 18:37 -0600, Kris Zyp wrote (in response to an
        email I sent him before I posted in this mailing list):


        > Paul,
        > This looks good, I'm glad you are working on this. A few comments:
        > * There are few things that seem overly verbose. To update a property
        > do you really need to a remove and add? It seems like the most common
        > use case would be to update a set of properties on an object. Wouldn't
        > it be preferable to do this in a more compact form? Being able to
        > provide a set of properties in an update object seems like it would be
        > a more efficient patch.


        Point taken. In an iteration prior to publishing draft 00, I actually
        had a "replace" op. It didn't take an array replacements; I was still
        relying on each node to be identified by a path (so multiple replace
        operations). It sounds like you'd like to have an array of
        property-modifications; something like a splice for objects. Am I right?


        > * It would seem that it would be nice to be able to insert/splice
        > elements in and out of arrays, so the entire arrays (or all indexes
        > after a splice) wouldn't have to be changed.


        Remove/add will do this too, but I presume the issue is the amount of
        verbosity involved?


        > * In JSON Schema we have abandoned using JSONPath. JSONPath really
        > doesn't have that signficant of adoption, and using URL friendly slash
        > delimiting and URL encoding works better within URLs and within JSON
        > strings (so you don't have to embedded quoting). See
        > http://tech.groups.yahoo.com/group/json/message/1473?threaded=1 for
        > more discussion on the subject.
        > (if you want this discussed on the JSON ML, feel free to switch over
        > there).


        Okay. I definitely see RESTful advantages to using fragment identifiers
        for sub-resource addressing. And this isn't the first pushback to using
        JSONPath I've received. Would you consider splitting fragment
        identifiers out of JSON Schema into a separate, short I-D that we can
        both reference?

        Paul


        [Non-text portions of this message have been removed]
      • jkrogsboell
        Hi Paul, First, I like the idea of updating a json document with a json document containing change and from my point of view you almost got it right :). My
        Message 3 of 3 , Apr 25, 2011
        • 0 Attachment
          Hi Paul,

          First, I like the idea of updating a json document with a json document containing change
          and from my point of view you almost got it right :).

          My first remark is that the element key could be removed and moved into the path key. The first example could then be rewritten to:

          {
          "patches": [
          { "op": "remove", "path": "$.a.b.c" },
          { "op": "add", "path": "$.a.b.c", "value": "foo" }
          ]
          }

          or just

          {
          "patches": [
          { "op": "add", "path": "$.a.b.c", "value": "foo" }
          ]
          }

          If we can agree that "add" is also an update if the path exists.

          My second remark is that you assume zero-indexed arrays as does JSONPath by goessner, but JSON actually doesn't mention that. And for a good reason: the less we have to a agree on, the more likely is it that the standard will be accepted and implemented (also no dates or timestamps in JSON).

          So perhaps there should be an entry in the JSON Patch document which specifies what index base is being used.

          Third remark: You say that path must resolve to a single node, then perhaps JSONPath is overkill in comparison to what you want to do. JSONPath is very powerful but also complex and unlikely to be implemented widely across JSON-implementations (a must for making JSON Patch widely accepted). Perhaps you should write a simple grammar for JSON Patch path values.

          In my little JSON implementation, PL/JSON, i've written a small grammar that you can steal or modify if you wan't. Then your open issue 1 will also be resolved.

          You can read about the grammar on page 5-7 in the file doc.pdf from http://sourceforge.net/projects/pljson/ . The main difference is that you don't specify the root element and that double quotes also are allowed. Ohh and it uses one-based indexing, but that could easily be modified.

          Hope that you can use some of my suggestions.

          /Jonas

          BTW: Is it legal to add information in a JSON Patch document that specifies where or how to find the document that should be patched?

          --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
          >
          > I've published an informational Internet-Draft for JSON Patch, a
          > proposed structure for specifying partial modifications to JSON
          > documents. You can see it at:
          >
          > http://tools.ietf.org/html/draft-pbryan-json-patch-00
          >
          > One of the primary motivations is to have a media type that can be used
          > with HTTP PATCH (RFC 5789).
          >
          > Any feedback would be most appreciated.
          >
          > Paul
          >
          >
          > [Non-text portions of this message have been removed]
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.