KevinDockx
commented
5 years ago That's indeed one of the shortcomings of the standard, essentially rendering array patches for updates/deletes useless (imo).
There's a Github repo (https://github.com/json-patch/json-patch2/) that tracks possible changes to the RFC, but there's nothing concrete atm as far as an update to the standard is concerned.
That said: some people are already implementing this. More specifically, @ChainReactive (see issue https://github.com/json-patch/json-patch2/issues/20) has been working on this and seems to have a working example up and running over on chainreactive.org.
I know from my own reading on the subject that the spec does not allow a collection to be patched by any sort of identifier because it uses JsonPointer instead of JsonPath.
So path = "/collection/{id=434}/property" can't be done. It has to be done by ordinal position. This really is a bad thing if the source collection and patching reference aren't sorted in the same way and the item in the number 3 position might not be the same item in the number 3 position being updated.
I am surprised over the years nobody has done anything about it, at least not that I've been able to find.
My question is how hard would it be to hack in something that could allow an identifier instead of a position?
Probably the correct way of doing this is to not allow it to begin with and have an endpoint for every collection and patch the property through that endpoint. In that case, what is the easiest way of detecting an attempted change to a collection from the root resource patch method so it can be stopped?
Last question since I know you've done some work on this with Core -- are there any notions about changing the JsonPointer to JsonPath in the spec itself moving forward?