2

Up until now I've used only GET and POST to do just about anything, however, it was brought to my attention that it would be better if I used Put, Patch and Delete as well. I've gone over them and realized how they would help me. For example my routes would look better as I'll have this:

Route::get('/image/{id}', 'PagesController@specificImage')->name('specificImage');
Route::delete('/image/{id}', 'ArtworkController@deleteImage')->name('deleteImage');

instead of this:

Route::get('/image/{id}', 'PagesController@specificImage')->name('specificImage');
Route::get('/deleteImage/{id}', 'ArtworkController@deleteImage')->name('deleteImage');

However, I've read some stuff which make me have doubts.

  1. I've read that Apache ( which I'm using ) doesn't allow PUT and DELETE unless you make some changes to the htaccess file. I assume the reason for that is number 2.

  2. I've read that PUT and DELETE are not secure.

  3. I've read that HTML forms only allow GET and POST. I do know that you can bypass that using hidden input fields which have the method you want to use in their value but I still have to ask myself why is it forbidden to use PUT and DELETE by default.

Onyx
  • 5,186
  • 8
  • 39
  • 86
  • Laravel bypasses all of the problems above through form method spoofing: https://laravel.com/docs/5.7/routing#form-method-spoofing Whether to use them or not depends entirely on you, really - there's no correct answer, just a matter of opinion. – Joel Hinz Dec 08 '18 at 12:30
  • Let's say I start working in a company as a web developer. Would I be required to use PUT, PATCH and DELETE? Would the more senior developers use them? – Onyx Dec 08 '18 at 12:32
  • Some yes, some no. There is no clear consensus. It takes five minutes to learn how to use both, and when you get a web dev job, you'll find out in five minutes which method your company prefers. – Joel Hinz Dec 08 '18 at 12:57

1 Answers1

2

What you should or shouldn't use comes down to your preferences in the end. The usage of HTTP methods can be considered quite opinionated. Also, there are quite some questions and resources out there.

But let me try to answer your questions to the best of my knowledge.

Request methods are specified in RFC 7231, section 4: Request methods

The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.

As you've stated, you can neglect them and bind the purpose to the URL. It is up to your server side implementation whether you evaluate the request method and act upon it, but as you stated

For example my routes would look better as I'll have this

Regarding your (probably) most important question:

  1. I've read that PUT and DELETE are not secure.

I can't verify that claim. The request method is just a simple header token of an HTTP request and doesn't change the behavior of request, nor does it affect the responder, if he doesn't evaluate it.

From my personal experience, a lot of small companies and developers don't use http methods, but only get and post, as they are the only methods supported by a default html form. This means, that if you want to send a PUT or DELETE, you have to take additional measures via javascript.

I've read that Apache ( which I'm using ) doesn't allow PUT and DELETE unless you make some changes to the htaccess file. I assume the reason for that is number 2.

In some apache default installations, PUT and DELETE need to be allowed explicitly. See this question for example. As to why it's not default, I can only assume that in many cases it isn't used anyway und reduces the amount of processed, but undesired requests.

Now regarding

  1. I've read that HTML forms only allow GET and POST. I do know that you can bypass that using hidden input fields which have the method you want to use in their value but I still have to ask myself why is it forbidden to use PUT and DELETE by default.

HTML forms only support GET and POST. To bypass this, you can't use hidden input fields, which would just populate the request body, but have to use javascript and set the request method explicitly. I've found this really good answer regarding the reason why HTML don't support PUT and DELETE. Two takeaways:

  1. caching is an issue as POST and GET should be cachable, but PUT and DELETE should not
  2. nobody bothered specifying it comprehensively.

Long story, short

Usage of PUT and DELETE can help you in writing clean code and web interfaces. The help you by putting more semantic to requests. Whether you use them or not is up to you. There are probably more websites ignoring them than using them, but with increasing size, the benefit will increase.

Community
  • 1
  • 1
Goatfryed
  • 118
  • 6