Should I link to a link that should be idempotent?

Question

So, we have a link to unsubscribe - this is an HTTP GET by nature.

the corresponding RFC says that this should be idempotent, but, in my opinion, what the user expects is that they click the link to make a decision.

I implemented this so that the link takes you to a page with a large confirmation button, which then updates your subscription, confirms this and displays the final status of your account (we have more than one type of subscription)

But I wonder if this will not be the best UX if a person just skips the confirmation button button ...

The answer to the question: "Am I up to something?" certainly yes, but I wondered what people are considering in order to balance the best practice of the GET idempotent with the best practice not to confuse users' expectations ...

Answer 1

I would say that it does not matter that RFC2616 in section 9.1.2 says because you already violate the much more important definition in section 9.1.1:

In particular, it was found that GETs and HEAD Methods SHOULD NOT have the value of taking action other than searching.

Imagine that a web guru (such as Google) follows all links from one of your pages containing that link. Are you really valid to trigger a unsubscribe operation? It will definitely be a bad user interface!

Answer 2

Idempotent means, in this context, that no matter how many times you click on a link, it will do the same, that is, unsubscribe. There were some solutions that will re-sign you if you return, a kind of flip-flop approach, i.e. Non-idempotent. Whether you make this as an immediate unsubscribe (my preferred approach as a user who is motivated enough to click a link is sure that what they want to do) or a confirmation page is up to you. Just make sure that no matter how many times the user clicks on your link and ends the process that they are, at the end of it, still does not subscribe from your list.

Answer 3

An interesting question is not whether it is idempotent, but safe. This is not so, therefore a simple GET (which, for example, can be preprogrammed) is incorrect.