You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the limitations of JSON patch that causes me problems in practice is that I can't add to an array if it isn't there and I also can't add the array without blowing away any existing array. [Perhaps there is a way of doing this that I don't know.]
I noticed that it is trivial to modify the code to allow '/foo/-' to create the array if it's not there. I understand that implementing non-standard extensions to JSON patch is going to create a lot of resistence, but it does make it a lot more useful. So I thought I'd see what the reaction to the idea was.
The text was updated successfully, but these errors were encountered:
Hi Martin, I'd rather not implement non-standard extensions in the library, there are just too many problems it could create. One option would be to talk to the group at IETF about the standard, maybe there'll be another revision at some point.
That would probably be my response in your position. Thanks for taking the time. Since the function is so useful, I'm using a modified version of the code. I should probably also use a modified media type. Maybe 'x-application/json-patch-plus+json'
One of the limitations of JSON patch that causes me problems in practice is that I can't add to an array if it isn't there and I also can't add the array without blowing away any existing array. [Perhaps there is a way of doing this that I don't know.]
I noticed that it is trivial to modify the code to allow '/foo/-' to create the array if it's not there. I understand that implementing non-standard extensions to JSON patch is going to create a lot of resistence, but it does make it a lot more useful. So I thought I'd see what the reaction to the idea was.
The text was updated successfully, but these errors were encountered: