Howdy -- actually, the fact that you use GET or POST doesn't make any difference *technically* as to whether it is idempotent (safe from bad effects of multiple executions) vs. NOT idempotent (like the example on 112/113).
What is confusing about it is that while you can make GET or POST idempotent or NOT, by how you develop the web app, the HTTP spec says that GET is idempotent while POST is not. But again, there is nothing to prevent the developer from doing the wrong thing by using, say, GET request parameters in the query
String to update the server (which would be NOT idempotent).
So, there is nothing *technically* that makes GET or POST inherentely idempotent or NOT idempotent, but according to the HTTP spec,
you should consider that GET is always idempotent--which means that a developer using it the right way should NEVER be using GET to do something that is not idempotent. On the other hand, you should assume that POST is *not* idempotent--because it is typically used to update something on the server, and thus if you want the web app to work correctly even if someone hits the submit button twice in a row, it is up to the developer to create/develop the whole app in such a way that this does not cause a problem.
On the exam, GET is idempotent and POST is NOT idempotent, because we use what the HTTP spec says about it. If you were to look at code in a web app, again, you might find someone using GET in a non-idempotent way and POST in an idempotent way, but that is a different issue.
I probably just made this even more confusing
-Kathy
