Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Mixing GET with POST - is it a bad practice?

Is it a bad practice to mix GET and POST? (note this is in PHP)

e.g.

<form action="delete.php?l=en&r=homepage" method="post">  <!-- post fields here --> </form> 
like image 846
mauris Avatar asked Oct 20 '09 04:10

mauris


People also ask

Can we use GET and POST together?

The question is, can you use GET and POST method together to create different dynamic pages from a single script? The answer is yes! Just check in the online demo, to see what we are talking about, and advanced users can just download the script to learn by themselves.

Does it matter if you use GET or POST?

Use GET if you want to read data without changing state, and use POST if you want to update state on the server.

What happens if you use GET instead of POST?

As with submitting any form data, you have the option of submitting your data in the form of GET requests, and you will save a few lines of code if you do so. However, there is a downside: some browsers may cache GET requests, whereas POST requests will never be cached.

Can you POST without request body?

Yes, it's OK to send a POST request without a body and instead use query string parameters. But be careful if your parameters contain characters that are not HTTP valid you will have to encode them.


1 Answers

Actually, this will send a POST request request to the server, so technically you aren't mixing the two together : you are using POST with url parameters. There is nothing fundamentally wrong with this, as long as you don't use your URL for parameters that should be in the form as hidden field.

There are simple rules : you use GET (possibly with URL parameters) for constant things that do not change the server, and POST for thing that modify the server. If your url parameters contained the ID of something you wanted to delete, then it would be bad practice.

EDIT, years later

I was asked for source, so here are the relevant part of the very spec of HTTP

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

There you go, GET should not change anything, POST is for thing that change the server (unsafe operation). I should be able to call GET any number of time. It is more than idempotent : it's should be (as much as possible) side-effect free! With GET the request may not even reach the server if caching is involved.

So yeah : you have a form, want to know if you use GET or POST? Then change server => POST, don't change server => GET. And since a URL can be accessed with any verbs (get or post), don't put the data that change the server in the URL, because someone may copy that URL, do a GET and change your server without you knowing. Imagine what would happen if someone copied that URL on facebook and 10 000 people started to delete random things? Not good. Recent framework (node, ruby) are better insulated against that, but not basic PHP, so it's a good rule of thumb for that language.

like image 52
Laurent Bourgault-Roy Avatar answered Sep 27 '22 22:09

Laurent Bourgault-Roy