What is the practical difference for a simple Soviet laraveler in handling POST, PUT and PATCH?

Question

RESTful API

If we descend from heaven to sinful earth, then is there any practical difference for me whether I accept POST, PUT or PATCH from the front, say, of this form:

/api/user/1234

{"name":"Vasia","age":27}

Let's say this is PATCH - i.e. I am doing a user data update.

But purely practically , in terms of code, will there be any differences depending on whether it is POST, PUT or PATCH, except in routes?

Answer 1

The difference is that they are different routes. no need to create users/123/update and users/133/delete. 1 url users/123 with 3 methods = 3 urls and everything is clear what everyone is doing. For Laravel, it is especially critical because he uses resource routes for which all these methods are invented. and if laravel is not used in laravel, then yes - deleting a get request or other similar shit options will work without any of those restrictions, exceptions, etc.

Answer 2

POST - create entity
PUT - update entire entity
PATCH - update part of entity

Answer 3

It was all invented many years ago when websites consisted of static files, and all these methods were applicable to them.
HTTP was invented much earlier than the rest. In rest, we do not have the put, path method. The rest is not the head method.
http methods are not the same as crud methods.
Therefore, how to implement your rest is purely your choice.
There is a significant difference between get and post.
Well, I still use delete. I never use put and path.
Everything is decided by documentation. Rest is not a rigid standard, but a set of practices for organizing api
. Once upon a time, wsdl was held in high esteem, everything was rigid and according to the protocol.

Answer 4

From a practical point of view, an important difference is that GET, POST are natively supported by http clients and browsers. And PUT, DELETE, PATCH, etc. - not everywhere and you have to emulate through a hidden field in the case of Laravel.