Have seen JSON patch successfully reduce complexity in two separate projects now. My thoughts: The Good: 1. Depending on your ORM or data access model, JSON p

Have seen JSON patch successfully reduce complexity in two separate projects now. My thoughts: The Good: 1. Depending on your ORM or data access model, JSON patch is a fantastic option. If you’ve got existing services that can hand you deeply nested models, you can start writing PUT/PATCH routes that take JSON patch changesets and let it build things up automatically. Makes it as easy as checking a resource out of storage, applyPatch or applyOperation, check it back in. 2. You don’t really need to worry about bad types getting dumped into your base object, as you should be deferring type safety to the route DTO level anyway, and everything can trickle from there. 3. The ‘-‘ semantic works fine for signaling an intent to insert a new element. 4. 99% of the time the “protocol” seems to just work. 5. YMMV, but there’s a good chance that switching to JSON patch will let you delete front end code as well, since the front end models can in theory also use the very commands they pass to the back end to locally update models. It integrates very well with a redux pattern and seems like a base technology for undo/redo. The Bad: 1. On the one hand ‘/‘ as the primary delimiter irks me. I suppose ‘.’ characters in a property name are more common than slashes, but still not my favorite. Furthermore, the escaped characters not using backslashes is weird. You write ~0 if you need to refer to ~ literally and ~1 for /, if I am not mistaken. 2. There’s a missing contextual mode for the ‘add’ op: creating missing objects along the path you’re talking about. For instance if your base object is {}, then add at path ‘/foo/bar’ will fail since foo is undefined. Should be a mode where I can say “yes, please create missing stuff along the way, thank you.” “On the JSON patch, feel your GraphQL cravings subside in as little as thirty minutes!”