This document proposes design patterns for robust asynchronous notification using REST. It introduces the Monitor pattern which creates a managed observe relationship between resources using a defined link relation and parameters. It also introduces Events, which are represented as REST resources within an observable collection, to handle state changes that require more than simple notification, such as alerts that have a lifecycle of being generated, acknowledged, and cleared. Examples of using Monitor links to update resources based on changes in other resources, subscribe to MQTT topics, and publish updates to topics are also provided.

1. REST Design Patterns for Robust
Asynchronous Notification
Using simple observe/notify to build a
robust and reusable design pattern for
asynchronous notifications
Michael J Koster

2. Problems
• Observe is not a well managed relationship
– The list of observers is hidden server state
– Client can't be certain if it is still in the list
– Conditional Observe is difficult to manage
• Events have life cycle beyond one notification
– Alerts are generated, acknowledged, and
eventually cleared
– Use cases for asynchronous Event delivery, polling,
and batch Event processing

3. Design Patterns
• Monitor
– Create a managed Observe relationship using a
REST resource with a defined link relation and
parameter set
• Events
– REST resource to represent an Event instance
– Maintain Event instances in an observable
collection

4. Monitor
• Use the IANA registered "monitor" link relation
– Description: Refers to a resource that can be used to monitor
changes in an HTTP resource (RFC5989)
– Similar to "boundto" (dynlink) but defines a unidirectional state
update from context to target.
• A Monitor may use Observe on the server to obtain state
changes of the context resource
• A Monitor may implement conditional notification using
filter parameters (dynlink) as well as defining transfer
methods and formats
• A Monitor may support multiple source and target
protocols based on URI scheme (mqtt, coap, http)
• Monitor parameters may be encoded as link attributes or
as properties of a monitor configuration resource

5. Monitor
Monitored
Resource
Observer FIlter Updater Monitor
Resource
Observe
Notify
Update
Reply
Context
Monitor
Target
accept
accept-method
accept-schema
accept-interface
pmin, pmax
lt, gt, st, eq
nbul, nbll, init
content-type
target-method
target-schema
target-interface

6. Monitor Patterns
Monitored
Resource A
Monitor
Monitor
Resource B
Observe
Notify
Update
Monitored
Resource A
Monitor
Monitor
Resource BNotify
Monitored
Resource A
Monitor
Monitor
Resource B
Observe
Notify
Update
Reply
Reply
Update
Reply
Observe
<>;anchor=A;rel=monitor<B>;rel=monitor
A Pushes State To B B Observes State From A
Remote
Update
Remote
Observe

7. Monitor Link Examples
Update a monitor resource when context is updated
"rel": "monitor",
"href": "monitor"
}
Update the context when a remote resource is
updated
{
"anchor": "coap://0m2m.net:5683/example/test",
"rel": "monitor",
"href": ""
}

8. Monitor Link Examples
Subscribe to an MQTT topic and update a resource
{
"anchor": "mqtt://0m2m.net/example/topic",
"rel": "monitor",
"href": "updated-on-mqtt-notify"
}
Publish updates on a resource to an MQTT topic
{
"anchor": "publish-updates-to-mqtt",
"rel": "monitor",
"href": "mqtt://0m2m.net/example/topic"
}

9. Events
• State changes that require more than simple
notification may be handled as Events
• Events may have a life cycle, like log records,
alerts, etc.
• A monitor may add state change notifications to a
collection of Event instances using CREATE
• The Event collection is Observable and transmits
newly created Event instances as notifications

10. Monitor Link to Event Collection
Create new event instances when events occur
{
"anchor": "/example/resource/event-emitter",
"rel": "monitor",
"href": "events",
"target-method": "create"
}
Push event notifications to a MQTT topic
{
"anchor": "events",
"rel": "monitor",
"href": "mqtt://0m2m.net/example/topic"
{