Mixing GET with POST - is it a bad practice?

Question

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>

Solution 1

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.

Solution 2

It's still a POST, you're just including a query string in the URL. I don't see a problem with this. This is probably cleaner that including those variables in the post data by using hidden input fields. Plus, on the server, you probably don't want the value of l (language?) with your post data. If it's always in the query string, you can the same code you elsewhere to determine the language, rather than having a special case for POST requests.

Solution 3

Nope, this is fine. I do exactly this on my company's web site, for example on the user admin page. The normal URL is:

/admin/user?name=jkugelman

Then to delete a user I post to this same page, except I POST a variable instead of doing a GET, since deleting is a stateful action and should be done with a POST. It looks something like this:

<!-- Post back to self -->
<form action="/admin/user?name=jkugelman">
    <input type="submit" name="delete" value="Delete"
           onchange="return confirm('Are you sure?')" />
</form>

Comments

[Kieron]

Well, ideally delete would be done with a DELETE action, if only HTML would let you.

[mauris]

i think this is quite a bad implementation if you ask me. i'll put the username in a hidden field.

[Jeroen Ooms]

This is over simplified. For one, GET should only be used if the action is idempotent.

[marc82ch]

This is a better answer than the one by John Kugelman. I believe including parameters that identify the program or environment are fine (e.g. ?action=deleteUser&language=en), even good practice maybe, where including the ID of something you want to act on is bad practice (e.g. ?userId=123). This belongs in a hidden field.

[atamanroman]

I'd like to see any backing resources for that statement.

[Laurent Bourgault-Roy]

I added the source. Make the response less concise, but better explained I believe.