Open xelamitchell opened 9 years ago
Hi @xelamitchell can you please clarify what you require in terms of changes to the json-patch libraries?
Thanks
Hey there @daveclayton. I was just looking for JsonPatch and JsonMergePatch classes to implement an interface of the type:
public interface Patch {
JsonNode apply(JsonNode node) throws JsonPatchException;
}
This way, independent of the operation type, a Provider can give me the appropriate Patch object (JsonPatch or JsonMergePatch) and the patch operation itself can be used transparently when validation of message happens in one level (Controller/Provider) and actual update (call to method apply(JsonNode)) happens in another (Service).
Many thanks
Hi
If I understand correctly, this is about pulling the apply method into an interface so that we can code to the behaviour instead of to the implementation (e.g. for IoC or Strategy, etc). Is that right?
There has been another question posted about splitting out interfaces and common objects into an API, so perhaps this should be tagged to that discussion so that we get the best solution overall.
What do you think?
Yes, isolating the apply method in an interface for dependency injection is the intent.
It certainly looks to me as though such an interface would be an important aspect for an API.
Hello,
Stumbled on the same issue than xelamitchell. A simple interface would be really useful to avoid duplication of code when one needs to provide both patch services.
In my API I wish to support both "application/json-patch" and "application/merge-patch" for deeply related and large entities. An example in a Spring Controller:
In this case, the actions before and after patch application are the same independent of which patch I am applying and the apply method shouldn't really care which patch it is applying as long as it is a valid patch for JSON.