リソースへのアクセスをカウントしたいのですが、HTTP GET はリソースを変更すべきではありません。リソースとともにカウンターが表示されます。同様のケースは、最後のアクセスを保存することです。
ビュー カウンターを実現する REST の方法は何ですか?
GET に反応してカウンタを更新することは、実際には HTTP プロトコルに違反していません。取得しているリソース、またはクライアントが制御できるその他のリソースを変更していません。
サーバーが GET に応答して更新を行うことを許可されていない場合、ログ ファイルは HTTP コントラクトに違反します。
RFC2616の関連部分は次のとおりです。
9.1.1 安全な方法
実装者は、ソフトウェアがインターネット上での対話においてユーザーを表していることを認識する必要があり、ユーザー自身や他のユーザーにとって予想外の重要性を持つ可能性のあるアクションをユーザーが認識できるように注意する必要があります。
特に、GET メソッドと HEAD メソッドは、検索以外のアクションを実行するという意味を持つべきではないという規則が確立されています。これらの方法は「安全」であると考えるべきです。これにより、ユーザー エージェントは、POST、PUT、DELETE などの他のメソッドを特別な方法で表すことができるため、安全でない可能性のあるアクションが要求されているという事実をユーザーに認識させることができます。
当然のことながら、サーバーが GET 要求を実行した結果として副作用を生成しないことを保証することはできません。実際、一部の動的リソースはそれを機能と見なしています。ここでの重要な違いは、ユーザーが副作用を要求したわけではないため、副作用について責任を負うことはできないということです。
最初に注意すべき重要なことは、「してはならない」ではなく「すべきではない」ということです。副作用が有効な場合があります。
2 番目の重要な行は最後の行で、ユーザーが変更を希望してリクエストを行っていないという事実を強調しているため、クライアントの期待に反するようなことが起こらないようにするのはサーバー次第です。これが「一様界面制約」の本質です。サーバーは、クライアントが期待することを行う必要があります。これは、クライアントが発行するものとは大きく異なります。
GET /myresource?operation=delete
この場合、クライアントは検索を行っていると考えます。クライアント アプリケーションがハイパーメディアの制約を尊重している場合、URL の内容は完全に不透明になるため、クライアントが理解できる唯一の情報は動詞 GET です。サーバーが実際に削除を行った場合、それは統一インターフェイスの制約に対する明らかな違反です。
内部カウンターの更新は、統一インターフェイスの制約に違反しません。取得される表現にカウンターが含まれる場合、まったく新しい一連の問題が発生しますが、そうではないと仮定します。