用一次 GET 换来的推送
在普通 GET 请求里加上观察选项，服务端把客户端登记为订阅者，此后资源每次变化都主动发送通知，通知里同样带观察选项与一个递增序号。客户端比较序号就能判断这条通知是新数据还是乱序到达的旧数据。取消订阅的方式是对最近一次通知回复复位报文，服务端据此移除订阅关系。
基本信息
| 登记方式 | GET 请求携带观察选项，取值 0 表示登记，1 表示取消 |
|---|---|
| 通知形式 | 响应报文同样携带观察选项与递增序号 |
| 序号作用 | 识别乱序与过期通知，新通知的序号应更新于旧值 |
| 取消方式 | 对最近一次通知回复复位报文 |
| 中间设备 | 部分缓存代理不支持观察，需要确认整条链路的能力 |
适用与不适用
| 数据特征 | 是否适合观察 | 原因 |
|---|---|---|
| 状态变化不频繁 | 适合 | 有变化才推送，省流量也省电 |
| 高频采样数据 | 不适合 | 通知频率高，反而接近持续推送 |
| 需要历史序列 | 不适合 | 观察只给最新值，历史需另存 |
| 跨公网长链路 | 谨慎 | 链路中断后订阅状态需要重新确认 |
典型使用场景
- 设备状态监控：只在状态变化时推送，避免轮询开销
- 配置变更生效：资源变化即通知管理端，缩短生效确认时间
- 报警上报：状态位翻转即推送，适合低功耗设备
- 资源发现配合：先发现设备资源，再按需建立观察关系
观察关系依赖链路可达性：长时间没有通知时，客户端应主动用一次普通 GET 重新确认资源状态并重新登记。
取消订阅的通知可能丢失，服务端会残留无效订阅关系并继续发送通知，服务端需要设置订阅数量上限与老化策略。