3 ms·

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 d

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".

kukkamario 2y ago
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.
- graypegg 2y ago
  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.
  - mattmanser 2y ago
    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.
  - vlowther 2y ago
    $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.
    - CrimsonRain 2y ago
      Who generates the test op? Client? Or the server?
  - kchr 2y ago
    Can you elaborate on how this affects the security model?
DataOverload 2y ago
You might like JSON Merge Patch then - much simpler syntax that avoids the URL stuff
ks2048 2y ago
IMHO, the "JSON patch" concept is useful in contexts that have nothing to HTTP, just like having a "diff" format for files.

kukkamario 2y ago

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.

graypegg 2y ago
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.
- mattmanser 2y ago
  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.
- vlowther 2y ago
  $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.
  - CrimsonRain 2y ago
    Who generates the test op? Client? Or the server?
- kchr 2y ago
  Can you elaborate on how this affects the security model?

DataOverload 2y ago

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

ks2048 2y ago

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