3. クライアント側の要件 (Client-Side Requirements)
3.1. 要求 (Request)
クライアントは、Observe オプションを 0 (登録) に設定した GET 要求を発行することにより、リソースへの関心を登録します。サーバーが Observe オプションも含む 2.xx 応答を返した場合、サーバーはターゲットリソースのオブザーバーのリストにクライアントエンドポイントと要求トークンを含むエントリを正常に追加しており、クライアントにはリソース状態の変更が通知されます。
サーバーに接続せずに新しい応答を使用して要求を満たすことができるのと同様に、1 つの観察要求から生じる更新のストリームを使用して、ターゲットリソースが同じであれば、別の (観察または通常の GET) 要求を満たすことができます。クライアントはそのような要求を集約しなければならず (MUST)、同じターゲットリソースに対して複数回登録してはなりません (MUST NOT)。ターゲットリソースは、キャッシュキーの一部である要求内のすべてのオプションによって識別されます。これには、たとえば、完全な要求 URI と Accept オプションが含まれます。
3.2. 通知 (Notifications)
通知は、登録を作成した単一の拡張 GET 要求への返信としてサーバーによって送信される追加の応答です。各通知には、要求でクライアントによって指定されたトークンが含まれます。通知と通常の応答の唯一の違いは、Observe オプションの存在です。
通知には通常、2.05 (Content) 応答コードがあります。これらには、並べ替え検出用のシーケンス番号 (セクション 3.4 を参照) を持つ Observe オプションと、初期応答と同じ Content-Format のペイロードが含まれます。クライアントが GET 要求に 1 つ以上の ETag オプションを含めた場合 (セクション 3.3 を参照)、通知には 2.05 (Content) 応答コードではなく 2.03 (Valid) 応答コードが含まれる場合があります。このような通知には、シーケンス番号を持つ Observe オプションが含まれますが、ペイロードは含まれません。
リソースが変更され、その時点で通常の GET 要求が非 2.xx 応答を返すような場合 (たとえば、リソースが削除された場合)、サーバーは適切な応答コード (4.04 Not Found など) を含む通知を送信し、リソースのオブザーバーのリストからクライアントのエントリを削除します。非 2.xx 応答には Observe オプションは含まれません。
3.3. キャッシュ (Caching)
通知は GET 要求に対する単なる追加の応答であるため、通知は RFC 7252 [RFC7252] のセクション 5.6 で定義されているようにキャッシュに関与します。鮮度モデルと検証モデルの両方がサポートされています。
3.3.1. 鮮度 (Freshness)
クライアントは、通知を応答のようにキャッシュに保存し (MAY)、サーバーに接続せずに新鮮な保存された通知を使用できます (MAY)。応答と同様に、通知はその経過時間が Max-Age オプションで示された値を超えていない (かつ、より新しい通知/応答が受信されていない) 限り、新鮮であると見なされます。
サーバーは、クライアントによって観察されるリソースの状態を実際の状態と可能な限り同期させるために最善を尽くします。ただし、クライアントは、リソースが通過する可能性のあるすべての状態を観察できるとは限りません。たとえば、ネットワークが混雑している場合や、ネットワークが処理できるよりも頻繁に状態が変化する場合、サーバーは任意の中間状態の通知をスキップできます。
サーバーは Max-Age オプションを使用して、観察された状態と実際の状態が不一致であることが許容されるまでの経過時間を示します。最新の通知の経過時間が示された Max-Age よりも大きくなった場合、クライアントは、同封された表現が実際のリソース状態を反映していると想定してはなりません (MUST NOT)。
現在の表現を持っていることを確認するため、および/またはリソースへの関心を再登録するために、クライアントはいつでも元の要求と同じトークンを持つ新しい GET 要求を発行できます (MAY)。ETag オプションのセットを除き、すべてのオプションは元の要求のものと同一でなければなりません (MUST)。キャッシュにリソースの新鮮な通知/応答がある間は、クライアントが要求を発行しないことが推奨されます (RECOMMENDED)。さらに、クライアントは、他のクライアントとの衝突を減らすために、Max-Age が期限切れになった後、少なくとも 5 ～ 15 秒の間のランダムな時間待機すべきです (SHOULD)。
3.3.2. 検証 (Validation)
クライアントがリソースの 1 つ以上の通知をキャッシュに保存している場合、GET 要求で ETag オプションを使用して、サーバーに使用する保存された通知を選択する機会を与えることができます。
クライアントは、GET 要求に適用可能な各保存された応答の ETag オプションを含めることができます (MAY)。観察されたリソースが ETag オプションの 1 つによって識別される表現に変更されるたびに、サーバーは 2.05 (Content) 通知の代わりに適切な ETag オプションを持つ 2.03 (Valid) 通知を送信することによって、保存された応答を選択できます。
クライアント実装は、ターゲットリソースに関心がなくなるか、新しいエンティティタグのセットで再登録するまで、すべての候補応答をキャッシュに保持する必要があります。
3.4. 並べ替え (Reordering)
通知を含むメッセージは、送信された順序とは異なる順序で到着する可能性があります。目標は、観察された状態を実際の状態と可能な限り同期させることであるため、クライアントは、到着順序に関係なく、最も最近送信された通知を最新のものと見なさなければなりません (MUST)。
クライアントに通知間の順序を提供するために、サーバーは各通知の Observe オプションの値を、厳密に増加するシーケンス番号の下位 24 ビットに設定します。次の条件のいずれかが満たされる場合、着信通知はこれまでの最新の通知よりも最近送信されたものです。
(V1 < V2 and V2 - V1 < 2^23) or
(V1 > V2 and V1 - V2 > 2^23) or
(T2 > T1 + 128 seconds)
ここで、V1 はこれまでの最新の通知の Observe オプションの値、V2 は着信通知の Observe オプションの値、T1 はこれまでの最新の通知のクライアントローカルタイムスタンプ、T2 は着信通知のクライアントローカルタイムスタンプです。
設計上の注意: 最初の 2 つの条件は、24 ビットシリアル番号演算 [RFC1982] において V1 が V2 より小さいことを検証します。3 番目の条件は、サーバーがローカルクロックに基づいてシリアル番号を生成している場合、2 つの着信メッセージの間に経過した時間が大きすぎて、V1 と V2 の差が 24 ビットシリアル番号に加算することに意味がある最大の整数よりも大きくならないようにします。つまり、通知なしで 128 秒が経過した後、クライアントは、着信通知がこれまでに受信した最新の通知よりも最近送信されたと想定するためにシーケンス番号を確認する必要はありません。
128 秒の期間は、MAX_LATENCY (RFC 7252 [RFC7252] のセクション 4.8.2) よりも大きい適切な概数として選択されました。
3.5. 送信 (Transmission)
通知は確認可能または確認不可能のいずれか、つまり、確認可能または確認不可能なメッセージで送信できます。通知に使用されるメッセージタイプは、要求および以前の通知に使用されたタイプとは無関係です。
クライアントが確認可能な通知内のトークンを認識しない場合、メッセージを確認してはならず (MUST NOT)、リセットメッセージで拒否すべきです (SHOULD)。それ以外の場合、クライアントは通常どおりメッセージを確認しなければなりません (MUST)。確認不可能な通知の場合、リセットメッセージでメッセージを拒否することは任意です (OPTIONAL)。
確認メッセージは、クライアントが生存しており、さらなる通知の受信に関心があることをサーバーに通知します。サーバーが確認可能な通知への返信として確認を受信しない場合、クライアントはもはや関心がないと想定し、最終的に関連するエントリをオブザーバーのリストから削除します (セクション 4.5)。
3.6. キャンセル (Cancellation)
リソースの通知を受信することに関心がなくなったクライアントは、単に観察を「忘れる」ことができます。その後、サーバーが次の通知を送信すると、クライアントはメッセージ内のトークンを認識しないため、リセットメッセージを返します。これにより、サーバーは関連するエントリをオブザーバーのリストから削除します。オブザーバーのリスト内のエントリは、サーバーによって効果的に「ガベージコレクション」されます。
実装上の注意: メッセージ損失の可能性があるため、リセットメッセージがサーバーに届かない場合があります。したがって、サーバーが最終的に関連するエントリをオブザーバーのリストから削除し、通知の送信を停止するまで、クライアントはそれぞれ 1 つのリセットメッセージを含む複数の通知を拒否する必要がある場合があります。
状況によっては、観察をキャンセルし、サーバーによって割り当てられたリソースをより積極的に解放することが望ましい場合があります。この場合、クライアントは、キャンセルする観察のトークンに設定されたトークンフィールドを持ち、値を 1 (登録解除) に設定した Observe オプションを含む GET 要求を発行することによって、明示的に登録解除できます (MAY)。ETag オプションのセットを除き、他のすべてのオプションは登録要求のものと同一でなければなりません (MUST)。サーバーがそのような要求を受信すると、オブザーバーのリストから一致するエントリを削除し、通常どおり GET 要求を処理します。