Question

So we have an unsubscribe link - this is by it's nature an HTTP GET.

The appropriate RFC says this should be idempotent but to my mind the user expectation will be that they are clicking a link to take an action.

I've implemented this so that the link takes you to a page that has a big confirm button which then updates your subscription, confirms that and displays the final state of your account (we have more than one type of subscription)

But I wonder if it would not be a better UX if the person simply skipped the confirm button stage...

The answer to the question "Am I overthinking this?" is definitely yes but I wondered what people's views were on balancing the best practice of an idempotent GET with the best practice of not confounding user's expectations...

Was it helpful?

Solution

I'd say it doesn't matter what RFC2616 section 9.1.2 says, because you're already violating the much more important definition in seciton 9.1.1:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.

Imagine the effect of a web-crawler (e.g., Google) following all the links from one of your pages that contains this link. Do you really want that to cause an unsubscribe operation? That would certainly be a bad user experience!

OTHER TIPS

Idempotent means, in this context, that no matter how many times you click on the link it will do the same thing, i.e. unsubscribe you. There have been some solutions that will resubscribe you if you return, a kind of flip-flop approach, i.e. non-idempotent. Whether you implement this as an immediate unsubscribe (my preferred approach as a user who's motivated enough to click the link is sure that's what they want to do) or a page with a confirm is up to you. Just make sure that no matter how many times a user clicks your link and completes the process that they are, at the end of it, still unsubscribed from your list.

The interesting question is not whether it's idempotent, but whether it's safe. It is not, thus a simple GET (which, for instance, might be prefetched), is wrong.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top