api-platform
JSON PATCH support
#147 suggested adding a PATCH support for partials updates, it was closed as PUT already does that.
How about adding a JSON PATCH support? Difference here is you're able to do operations WITH entities, not only ON entites, quoted from Why PATCH is Good for Your HTTP API
PATCH is atomic, which means that if you need to do some complex changes to the state of a resource, you can do it with confidence. It also means that you can create synthetic resources and PATCH them if you need to orchestrate changes to the state of several resources.
@dunglas given that the content-type of both methods is different, couldn't both be implemented? I understand that Merge Patch has limitations, but for many cases, it's simplicity could be great for certain applications.
What I mean is, I don't see why we should have to pick one or the other. They are just different formats and both could be supported. If that's ok with you, I might have a go at trying to implement merge patch, time permitting.
Yew we can support both. It should be possible to support JSON MERGE PATCH with just a few modifications to the current system.
Implementing JSON Patch will force us to improve our design. And it will allow us to deprecate the current partial PUT semantics (which is wrong). :smile:
@teohhanhui I don't see why both (JSON MERGE and JSON PATCH) can't be implemented. I don't disagree with you and I'm sure if a PR appears for JSON PATCH, @dunglas would be willing to merge assuming it passes review. In my use-case, the simplicity of JSON MERGE trumps the flexibility of JSON PATCH.
I'm okay with having both. :)
On 27 Feb 2017 22:19, "Alberto Simon" [email protected] wrote:
@teohhanhui https://github.com/teohhanhui I don't see why both (JSON MERGE and JSON PATCH) can't be implemented. I don't disagree with you and I'm sure if a PR appears for JSON PATCH, @dunglas https://github.com/dunglas would be willing to merge assuming it passes review. In my use-case, the simplicity of JSON MERGE trumps the flexibility of JSON PATCH.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/api-platform/core/issues/759#issuecomment-282732998, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhf615IQF9pQkU8tZdIzn-8SG20cehuks5rgttugaJpZM4KBoyo .
Also, I think we can deprecate the partial PUT once we have JSON Merge Patch. Because it already covers the existing semantics.
On 28 Feb 2017 11:53, "Teoh Han Hui" [email protected] wrote:
I'm okay with having both. :)
On 27 Feb 2017 22:19, "Alberto Simon" [email protected] wrote:
@teohhanhui https://github.com/teohhanhui I don't see why both (JSON MERGE and JSON PATCH) can't be implemented. I don't disagree with you and I'm sure if a PR appears for JSON PATCH, @dunglas https://github.com/dunglas would be willing to merge assuming it passes review. In my use-case, the simplicity of JSON MERGE trumps the flexibility of JSON PATCH.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/api-platform/core/issues/759#issuecomment-282732998, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhf615IQF9pQkU8tZdIzn-8SG20cehuks5rgttugaJpZM4KBoyo .
AFAIK, no. But we should probably consider using JSON Merge Patch instead: https://tools.ietf.org/html/rfc7386
@dunglas can this issue be closed in favour of https://github.com/api-platform/core/pull/1175 ?
JSON API is only one media type. This is about PATCH support for all of the supported media types, and I'd think especially JSON-LD / Hydra.
@dunglas IMO this shouldn't be closed in favor of JSON Merge since Merge is only a partial PUT.
JSON PATCH is a diff to a JSON document so, if a document represents a collection of your resources, you could:
- append a new resource into a collection
- remove a resource from a collection
- re-order (some) collection items without touching (or mentioning) the rest
It solves the partial collection management problem well and IMO it should be kept as a future option.
this seems a step too far at the moment.
for the moment, why can we not just make PUT mean PUT semantically, rather than PATCH? is is difficult?
EDIT: from slack
it seems not that hard? we know what attributes are writable for the PUT from serializer, so we can just
- treat missing as null. fill missing as null if not provided, or
- treat missing as error. throw error as not all required attributes were provided.
@bendavies Yes, but we need to make it opt-in for BC. And when we have proper JSON Patch support, we can deprecate not using the correct semantics.
Let's keep this open as we only support JSON Merge Patch, not JSON Patch.
#Hi, how do you manage partial Validation constraints with PATCH actions? I'm facing some problems to achieve this, but I do not have solution.
I opened an issue here: https://github.com/api-platform/api-platform/issues/1637
I am attempting to implement a subset of JSON Patch/RFC 6902 in order to partially update collections. See discussion https://github.com/api-platform/core/discussions/4882.
