According to the HTTP/1.1 spec:

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE should not have side effects, and so are inherently idempotent.

A common interpretation of idempotence is that it means GETs should not affect the server state in any way. I was talking to a friend who is big on the concept. (He pointed me to the spider of doom.) He theorized that proxying the SQL and watching for UPDATEs, INSERTs or DELETEs could give you a pretty solid programmatic test for idempotence. I think that is largely true, though there's the in-memory state to be concerned about and, what is important to me here, the persistent storage in cookies.

I'm working on a little script to show a tree. When someone clicks on one of the file folders, I want for it to expand that level of the tree. Which folders are expanded are stored in a cookie for persistence sake.

Now, by the rules of idempotence, the links to expand the tree should be POST requests since they will change how the page displays for future requests. The problem is that <a> tags perform a GET. There are two commonly used methods for dealing with this:

Currently, this is what the page looks like using <a>s:

I want to replace the <a>s with <form>s. That will look like this:

Ideally, the value of the <input> would be + or -. That way I could have a non-graphical style that would work as well. I can't think of any way to hide that text though without hiding the background as well. I may just add two submit buttons and always hide one. It would look funky in non-CSS browsers, but that is a very limited audience which should suspect some issues.