JSON Patch

I'm probably missing a use case here, but with the JSON Pointer spec they use feeling so "URL-y", couldn't you skip the whole meta-json syntax? So rather than doing

    HTTP/1.1 PATCH /user
    Content-Type: application/json-patch+json

    [
      {
        "op": "replace",
        "path": "/username",
        "value": "bob"
      }
    ]

why not

    HTTP/1.1 PATCH /user/username
    Content-Type: application/json

    "bob"

I feel like you could pretty sensibly implement replace/delete/append with that.

Edit: "test" and "copy" from the json patch spec are unique! So there is those, as well as doing multiple edits all at once in a sort of "transaction".

And then you'd be limited to only one change at the time and lose the benefit of making lot of changes with one request.

I do get that, just saw the "test" op, to either pass or fail the whole change as a sort of transaction. That is really neat.

But I just find that the 1 by 1 approach is easier to reason about if you're opening this up to the internet. I'd personally feel more comfortable with the security model of 1 URL + Session => 1 JSON key.

You might like JSON Merge Patch then - much simpler syntax that avoids the URL stuff

I'm actually using it at the moment in my work and I'm often doing 3-4 updates per patch.

You want them to all fail or not,

One-by-one is a bit of a weird suggestion tbh. You shouldn't be reasoning that way about code.

If you are going to get a 4xx response to one of the 4 property updates you want them all to fail at once.

Just like anything else we use like SQL.

$WORK project heavily utilizes the test op to enable atomic updates to objects across multiple competing clients. It winds up working really well for that purpose.

IMHO, the "JSON patch" concept is useful in contexts that have nothing to HTTP, just like having a "diff" format for files.

Can you elaborate on how this affects the security model?

Who generates the test op? Client? Or the server?