5 ms·

I feel like nearly every team which has worked with JSON for a certain number of projects automatically starts building out their own "spec" for how to handle a

I feel like nearly every team which has worked with JSON for a certain number of projects automatically starts building out their own "spec" for how to handle additions/deletions/updations to JSON instances on-the-fly. I've built atleast 3 different specs for what could be described at JSON-Patch for different projects, and each has a slightly different semantic. eg. in one implementation someone suggested in another comment, instead of explicitly passing an "operation", I just pass "key": null and it gets interpreted as delete everything below this key. In another case "key": null and "key" not existing are treated as different cases etc. TBH I'm glad that there's some form of standardization for this, but I wish it was more publicized so folks would stop building their own specs for this.

giancarlostoro 4y ago
Am I the weird one out, I've always just build plain old CRUD applications, never really had to PATH JSON, I have some alternative ideas, like just sending the lastUpdated value and ID's to the back-end and getting back any records that are far more up to date, but I wouldn't even bother diffing it, unless there's a good strategy for that, aside from caching it or some fancy database feature I've never heard of. Genuinely curious how you troubleshoot JSON-Patch it feels like something that adds more mental overhead than it would be worth if it breaks. I understand how it would work in practice from a front-end perspective, I'm unsure about the backend though. My issue is, if I know what's changed I rather just send the ID's and values that changed to the front-end at that stage, or just those records respectively.
- wvh 4y ago
  Patch and variations are popular in software such as Kubernetes, where multiple actors are writing to the same field sets. In distributed or highly concurrent environments it's quite likely to get a conflict on update, but in those situations where actors have interest in different subsets of the data, touching only those fields you "own" can avoid the read-update-conflict retry cycle.
tyingq 4y ago
It is sort of fun to watch the cycle where json replaced xml mostly because it was simpler. Then to see things that look like xslt, xpath, etc, come back around.
- Spivak 4y ago
  The tragic flaw of XML was that there was xml.parse equivalent that could take a generic XML document and map it to actually useful types. I guess you could get a Tree<XMLNode> but that's not really all that useful when people want arrays, numbers, hashes, and strings. XML could have been amazing with a common schema for "basic types" with a clear "next step" for structs.
  - Merad 4y ago
    XML is too flexible for its own good. It's not hard to come up with a simple XML schema for basic data that's functionally equivalent to json, but there are probably a dozen different ways that you could structure the schema to achieve the same result. And of course with XML being XML, most people trying to make that "basic type" schema would probably end up throwing in extra metadata, events, or things of that nature.
- HWR_14 4y ago
  I agree. It's one of those "why am I paying for all theses features no one uses" situations. An then everyone poorly reimplements the 10-15% of features they were using. And there are no standards for those 10-15%. Meanwhile, I'm actually not aware of any XML patch standard.
- wvh 4y ago
  That's true, but XML tends to map rather poorly to basic data types in common programming languages. With JSON you usually get to work with native objects or map structures; with XML, you're stuck with either tree or event APIs, which are a lot more complex and add another layer of indirection.
ellisv 4y ago
Yup. We implemented our own thing a few companies ago. It wasn't great but we didn't know about JSON Patch back then. It would have saved us a lot of time and pain.

giancarlostoro 4y ago

Am I the weird one out, I've always just build plain old CRUD applications, never really had to PATH JSON, I have some alternative ideas, like just sending the lastUpdated value and ID's to the back-end and getting back any records that are far more up to date, but I wouldn't even bother diffing it, unless there's a good strategy for that, aside from caching it or some fancy database feature I've never heard of. Genuinely curious how you troubleshoot JSON-Patch it feels like something that adds more mental overhead than it would be worth if it breaks. I understand how it would work in practice from a front-end perspective, I'm unsure about the backend though. My issue is, if I know what's changed I rather just send the ID's and values that changed to the front-end at that stage, or just those records respectively.

wvh 4y ago
Patch and variations are popular in software such as Kubernetes, where multiple actors are writing to the same field sets. In distributed or highly concurrent environments it's quite likely to get a conflict on update, but in those situations where actors have interest in different subsets of the data, touching only those fields you "own" can avoid the read-update-conflict retry cycle.

tyingq 4y ago

It is sort of fun to watch the cycle where json replaced xml mostly because it was simpler. Then to see things that look like xslt, xpath, etc, come back around.

Spivak 4y ago
The tragic flaw of XML was that there was xml.parse equivalent that could take a generic XML document and map it to actually useful types. I guess you could get a Tree<XMLNode> but that's not really all that useful when people want arrays, numbers, hashes, and strings. XML could have been amazing with a common schema for "basic types" with a clear "next step" for structs.
- Merad 4y ago
  XML is too flexible for its own good. It's not hard to come up with a simple XML schema for basic data that's functionally equivalent to json, but there are probably a dozen different ways that you could structure the schema to achieve the same result. And of course with XML being XML, most people trying to make that "basic type" schema would probably end up throwing in extra metadata, events, or things of that nature.
HWR_14 4y ago
I agree. It's one of those "why am I paying for all theses features no one uses" situations. An then everyone poorly reimplements the 10-15% of features they were using. And there are no standards for those 10-15%. Meanwhile, I'm actually not aware of any XML patch standard.
wvh 4y ago
That's true, but XML tends to map rather poorly to basic data types in common programming languages. With JSON you usually get to work with native objects or map structures; with XML, you're stuck with either tree or event APIs, which are a lot more complex and add another layer of indirection.

ellisv 4y ago

Yup. We implemented our own thing a few companies ago. It wasn't great but we didn't know about JSON Patch back then. It would have saved us a lot of time and pain.