Obeying the POST to modify data

Question

So I've read you should use POST for anything that could modify data.

E.g.

BAD

<a href="edit.php?id=12">Edit</a>

GOOD

<form action="edit.php" action="post"><input type="hidden" name="id" value="12" /><button type="submit">Edit</button></form>

Now obviously the first once is more terse, but it would be considered the wrong way to do it.

Now usually the extra markup isn't too bad of a problem, but say I might be displaying this markup 20 times, or perhaps more. And then there is the question of 'should it have a fieldset and legend elements for the form'.

What is the general best practice for this? Or have I got this thing back to front?

Answer 1

Generally when passing lots of data to the server to be processed or stored, using POST is a good idea, since GET has a lower limit than that of POST. POST also has the added benefit of being relatively hidden to the user, except during transmission if not encrypted.

If you're passing simple values like what you're passing above, however, then using GET isn't a problem (unless you like sleek URL's, that is..)

Answer 2

having a link with an id is fine, if you ensure id are id (like numbers) and you proper escapement

what is wrong is to post some form as GET like it make long url the user can bookmark it and that a bad move.

something like that would be not good

<form>
 <input type="text" name="firstname"/>
 <input type="text" name="lastname"/>
 ...
</form>

Also has good form policy I advice you to take a look at the POST/Redirect/GET policy.

Answer 3

It depends what visiting edit.php?id=12 does. Does it actually change something, or does it display another page that allows you to edit something?

If it's just displaying a page that allows you to edit something, then GET is fine. If it's actually changing something, then POST is the correct, semantic thing to do, and you have to deal with the fact that the markup is a bit bloated.

The practical problem with GET requests that modify data is that they might get followed by mistake - think bookmarks, back/forward buttons (many browsers display a warning if you try and re-submit a POST request this way), search engines following links etc.

Answer 4

Ok, you got your reason to not use GET correct.

Let's take an example. Suppose you have a script which increments or decrements a counter based on a radio button submission.

Let's say:

www.example.com/index.php?var=inc causes increment and www.example.com/index.php?var=dec causes decrement.

The problem is that if a user accidently refreshes, forwards or bookmarks the URL to your script, your counter will go nuts!

This is the classic case when you should prefer POST.

The other case obviously is when you are submitting sensitive information like passwords etc.

Answer 5

The best way I can summarize this is in two easy lists:

When POST is better than GET

• Other than duplicate form submissions, users are much less likely to accidentally duplicate a POST request since you can't bookmark POST requests, and if you click the URL bar and press enter the POST request won't resend all the data
• POST allows you to add files
• The POST whenever there's a state change also allows for an easier semantic distinction when programming the backend
• POST requests are easier to code since you don't have to serialize or escape user data POST requests done through forms are the norm, so it's much easier to tack on an AJAX plugin if you feel the urge in the future

When GET is better than POST

• GET requests can be bookmarked. Things like search queries should always be GET requests.
• If you decide to get uber-strict on page expiration (no-cache and the whole business), when users click back on their browser, pages generated with POST data will not resend the POST data to create the page, where as the GET request will remain the same as it was originally
• GET requests make more "sense" to some users

Regarding your specific problem, I infer that you want to take the user to a page where they can edit some page with ID=12. If this is the case, the link to the edit page should be a simple HREF with GET (you might want to consider using .htaccess rewrite to prettify your URLs so it looks like edit/12 rather than edit.php?id=12). The edit page itself should be a form that sends POST data.