API Platform version(s) affected: 3.1.2
Description
Since the merge of #4996 we are in a difficult situation without efficient workaround ATM.
In our API and because we are full CQRS, we don't use ReadListener for PUT operation.
We are ok that we are living on the edge but we are pretty happy with our combination of APIP and our architecture. And latest change in APIP3 were so great for us.
But with those lines added :
|
} elseif (HttpOperation::METHOD_PUT === $method && !($attributes['previous_data'] ?? null) && null === $status) { |
|
$status = Response::HTTP_CREATED; |
|
} |
All our PUT operation return now 201... And we have no way to get back the old behavior via the new standard_put properties.
How to reproduce
Create a PUT operation without ReadListener
Possible Solution
- We could update manually our
PUT operations to manually add status: 200. But I should admit I'm scared that we could forget one (now or in the future) that could lead to break someting in prod.
- Is there a world where the lines updated above could rely also to an additionnal condition where we could act on it ? Like allowCreate ?
We are open to any solid solution that would involve to add some custom code in our codebase of course.
API Platform version(s) affected: 3.1.2
Description
Since the merge of #4996 we are in a difficult situation without efficient workaround ATM.
In our API and because we are full CQRS, we don't use
ReadListenerforPUToperation.We are ok that we are living on the edge but we are pretty happy with our combination of APIP and our architecture. And latest change in APIP3 were so great for us.
But with those lines added :
core/src/Symfony/EventListener/RespondListener.php
Lines 93 to 95 in 9b4b58c
All our
PUToperation return now201... And we have no way to get back the old behavior via the newstandard_putproperties.How to reproduce
Create a PUT operation without ReadListener
Possible Solution
PUToperations to manually add status: 200. But I should admit I'm scared that we could forget one (now or in the future) that could lead to break someting in prod.We are open to any solid solution that would involve to add some custom code in our codebase of course.