Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PUT on /resource/non-existing-id should work according to the HTTP spec #4344

Closed
soyuka opened this issue Jul 1, 2021 · 4 comments
Closed
Milestone

Comments

@soyuka
Copy link
Member

soyuka commented Jul 1, 2021

See https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4

probably using merge in Doctrine.

@soyuka soyuka added this to the 3.0 milestone Jul 1, 2021
@rugolinifr
Copy link

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 ?

thanks in advance for your answer

@dunglas
Copy link
Member

dunglas commented Jul 3, 2021

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.

@rugolinifr
Copy link

Ok I see. I'll take a look at the PATCH method then.

Thanks

@soyuka
Copy link
Member Author

soyuka commented Jan 4, 2023

#4996

@soyuka soyuka closed this as completed Oct 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants