HTTP DELETE with a body ?

@Snapey The application is with VueJS for the front, so yes it's an API call.

What I thought about is for example use a patch request to soft delete the user and send the reason inside the body.

What do you think about this ?

Or as you say via the URL ... when you say url encode, you mean https://domain.com?reason=this_is_the_reason ?

@vincent15000 its not much of a stretch to say actually you are patching the user to 'inactive' by soft deleting since you are not actually destroying the record.

Depends how much you care about semantics and REST principles.

Yes, I did mean like https://domain.com/?reason=this_is_the_reason

@Snapey Well ... yes ... about semantics, I would say that a soft delete isn't a delete, it's rather an update of the deleted_at field.

What's the best pratice in Laravel for doing soft deletes ? Via an PATCH request or a DELETE request ?

Some members of the teams in which I work like to think that a soft delete should be a PATCH request. I agree with because the model isn't really deleted.

@vincent15000 I'd just use a put request for that. You are just updating the deleted_at column.

@jlrdw It's probably a good idea. In this case I can add a body to the request to pass the reason of the deletion.

What's the real difference between PUT and PATCH ?

I read that a PUT request is to replace all the fields whereas a PATCH request to merge the request with the existing datas. But in pratice it could be rather different because I could use a DELETE request to create a new model and not the delete one (sure which has no sense ;)).

Is there really a good reason to use PATCH instead of PUT ? Or i it just to respect a certain semantic (which is already a good reason) ?

@vincent15000 you have document type storage and you have field storage like innodb in mysql.

Laravel uses symfony request, so in the background it handles whether to turn it into a post request.

In regular request (crud), there is no put, patch or delete Symfony automatically turns them into a post request for you if needed.

@jlrdw ok thank you, that means that I only have to be logical with my code

@jlrdw @snapey Finally it was easier to write a new endpoint to post the reason just after having deleted the user. And the frontend will check that the connected user has explained the reason before deleting the user.