> A GET request should never delete something just because the URL says "method=delete".
More generally, a GET must not alter application state. It can change a cache or a logfile (these are either implementation detail or irrelevant), but if there is any way for the user to see what was changed, then it does not belong in a GET[0].
[0] things like consumption quotas management are of course a different matter, but they're meta-data more than application state.
Hmm that could work for an unsubscribe page, since the user is motivated to make the second click. However, for an email with a sign up link or a subscription confirmation link having an extra step could reduce your conversion rate somewhat.
but OTOH semantics of GET allow e-mail servers to implement a link scanner that e.g. checks all linked pages for phishing.
That breaks (and likely is broken already in practice) when pages don't respect semantics of GET and unsubscribe/verify, etc. when page is merely displayed.
More generally, a GET must not alter application state. It can change a cache or a logfile (these are either implementation detail or irrelevant), but if there is any way for the user to see what was changed, then it does not belong in a GET[0].
[0] things like consumption quotas management are of course a different matter, but they're meta-data more than application state.