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
Do you mean that the request must create if it does not exist ?
If so, I am a bit worried:
How to handle security ? for example, the current user is not allowed to POST the resource, but is allowed to PUT. What security rule/ voter is applied when the identified resource does not exist ?
How will behave security and security_post_denormalize keywords ?
What if the identified resource exists within the persistence storage, but it's excluded by the data provider because of some QueryItemExtensionInterface ?
What about resources with different denormalization groups on POST and PUT requests ? For example when you define a property at creation that can't be updated after ?
Basically our current PUT implementation behaves more or less like a PATCH. The idea here, now that PATCH is properly supported (that wasn't the case initially), is to respect the true semantic of the PUT request and to encourage using PATCH for the use cases you describe.
To prevent any BC break, we plan to introduce a new attribute in 2.7 (set to false by default, but triggering a deprecation warning is not set to true) to enable the standard behavior (if set to false, the current behavior will be preserved). In 3.0 we'll remove the non-standard behavior.
Activity
rugolinifr commentedon Jul 3, 2021
Do you mean that the request must create if it does not exist ?
If so, I am a bit worried:
How to handle
security
? for example, the current user is not allowed to POST the resource, but is allowed to PUT. What security rule/ voter is applied when the identified resource does not exist ?How will behave
security
andsecurity_post_denormalize
keywords ?What if the identified resource exists within the persistence storage, but it's excluded by the data provider because of some
QueryItemExtensionInterface
?What about resources with different denormalization groups on POST and PUT requests ? For example when you define a property at creation that can't be updated after ?
thanks in advance for your answer
dunglas commentedon Jul 3, 2021
Basically our current
PUT
implementation behaves more or less like aPATCH
. The idea here, now thatPATCH
is properly supported (that wasn't the case initially), is to respect the true semantic of the PUT request and to encourage usingPATCH
for the use cases you describe.To prevent any BC break, we plan to introduce a new attribute in 2.7 (set to false by default, but triggering a deprecation warning is not set to true) to enable the standard behavior (if set to false, the current behavior will be preserved). In 3.0 we'll remove the non-standard behavior.
rugolinifr commentedon Jul 3, 2021
Ok I see. I'll take a look at the PATCH method then.
Thanks
soyuka commentedon Jan 4, 2023
#4996