登録解除リンクがあります。これは、本質的に HTTP GET です。
適切な RFCでは、これはべき等であるべきだと述べていますが、私の考えでは、ユーザーはリンクをクリックしてアクションを実行することを期待しています。
私はこれを実装して、リンクが大きな確認ボタンのあるページに移動し、サブスクリプションを更新し、それを確認して、アカウントの最終状態を表示するようにしました (複数のタイプのサブスクリプションがあります)。
でも、単純に確認ボタンの段階を飛ばした方がUX良くないのかな…
「私はこれを考えすぎていませんか？」という質問への答え。確かにそうですが、べき等GETのベストプラクティスと、ユーザーの期待を混乱させないベストプラクティスとのバランスについて、人々の意見はどうなのかと思いました...
あなたはすでにセクション9.1.1のはるかに重要な定義に違反しているので、RFC2616セクション9.1.2が何を言っているかは問題ではないと思います。
特に、GETメソッドとHEADメソッドは、取得以外のアクションを実行することの重要性を持たないようにする必要があるという規則が確立されています。
このリンクを含むページの1つからのすべてのリンクをたどるWebクローラー（たとえば、Google）の効果を想像してみてください。本当にそれが購読解除操作を引き起こすようにしたいですか？それは確かに悪いユーザーエクスペリエンスになります！
興味深い問題は、べき等かどうかではなく、安全かどうかです。そうではないため、単純な GET (たとえば、プリフェッチされる可能性がある) は間違っています。
このコンテキストでの冪等性とは、リンクを何度クリックしても同じこと、つまり登録解除を行うことを意味します。あなたが戻ってきたら、あなたを再購読するいくつかの解決策がありました.一種のフリップフロップアプローチ、つまり非べき等です。これを即時の登録解除として実装するか (リンクをクリックするのに十分な動機を持つユーザーとしての私の好ましいアプローチは、それが彼らのやりたいことであることは確かです)、または確認のあるページとして実装するかどうかは、あなた次第です。ユーザーが何回あなたのリンクをクリックしてプロセスを完了したとしても、そのプロセスの最後に、リストからまだ登録解除されていることを確認してください.