Notifications on the Web
The Web is optimized for client-server access, meaning that servers do not speak to clients unless spoken to. Occasionally, users may wish to reverse this paradigm, so that a server can "push" new information to a client as soon as it becomes available.
For example, a user wishes to be notified when a blog post is published, when an email is received, or when a long operation has just completed.
There are are multiple different mechanisms that may be used to send a notification to a user, the best solution will vary depending on what the user prefers and is capable of receiving.
Classes of Notifications
Notifications may be classified based on the user's perspective:
- Was the notice emitted in response to a first-, second-, or third-party event? That is, was the user anticipating the notice (e.g. a payment accepted notification); was it generated by the sender (terms of service update); or was it another user entirely (a message was posted to a mailing list)?
- Does this happen on a recurring basis? For example, a delivery service may notify a customer about every package, even unsolicited packages; but the storefront filling the order will only send one "package delivered" message every time the user places an order.
- Is it sent to multiple people at once? For example a package delivery only notifies one person; a price drop may notify multiple people who each requested to be notified; and a chat message may notify the entire channel.
Transactional Notifications
Transactional notifications are typically emitted once, to a single user, in response to some previous request by a user. For example, a user account has been registered, a product has shipped, payment has been approved, or a batch operation has completed. These types of notifications are the type used by asynchronous HTTP operations.
Subscription Notifications
Subscription notifications are emitted to any number of people at once on a recurring basis. For example, a blog post has been published, or a marketing department is announcing a sale.
Most marketing emails are subscription notifications, even if they are customized for each user, or only sent to one user. However, some exceptions exist, for example, if a user has specifically toggled an option such as "Notify me when the price drops", this could be considered a transactional notification.
Mass Transactional Notifications
A mass transactional notification is a variation of a transactional notification that is delivered to multiple people (and so could also be considered subscription notification), typically in about an event by a third party. For example, a user pinged multiple people in a chat channel, or a message was posted to a mailing list. Is transactional in the sense that it happened in response to an event, but the receiving user views it like a subscription notification, because it happens on a recurring basis, and they may disable the notifications.
Email vendors that only permit transactional notifications may or may not permit a mass transactional notification, depending on the content and nature of the message; and different vendors will draw the line in different places.
Cascades of notifications
A notification can start a chain of other notifications, each of which might be classified differently. For example, a mass marketing email delivered to a user's inbox would be considered a subscription notification, but the fact that the email was received, when pushed to a user's mobile device by the user's email host, is a transactional notification.
On-demand Requests
On demand notifications are downloaded by the client whenever they check for new notifications. This typically involved issuing a GET request, and the server responds with a list of recent or new events.
Polling at regular intervals
When a user makes regular requests to check for notifications that may occur on a regular basis. This is the simplest, purely-HTTP method for checking for updates, but can needlessly consume resources and can delay receipt of notifications. This is typically combined with If-Modified-Since to only receive a response if the server has new information to be read.
Polling with exponential backoff
When a user-agent is expecting a transactional notification (that only happens once), it may be a better use of resources to increase the duration between refreshes.
Feed (Atom/RSS)
Standardized formats like Atom or RSS are designed to provide a list of messages as a feed.
Realtime Response
A realtime response is when the user connects to a server, and receives a message as a client on the connection.
Long polling
A technique where an HTTP server waits to respond to a request until it has new information. This may be implemented with If-Modified-Since, and a request header specifying to wait until there is new data, instead of responding with 304 (Not Modified).
Websockets
A datagram protocol specifically designed for shuttling arbitrary messages asynchronously, tunneled over HTTP.
HTTP 102 (Processing)
The 102 (Processing) HTTP status code may be used to indicate that something has happened, any time before the response has been generated. It cannot attach a payload, but the user may then make a request to retrieve the new information.
Realtime Push
A realtime push is when the service connects to a remote server operated by the user (or on behalf of the user).
Callback endpoint (Webhooks)
A technique where a user registers a URL endpoint with a service, with which notifications are delivered using a POST request to that endpoint. Implementations must be careful to check the authenticity of notifications, since the endpoint is typically accessible on the public Internet.
Perhaps the oldest and most well known real-time notification mechanism. Email supports sending signed machine-readable documents, but is typically used for sending formatted messages for people to read.
Web Push
A protocol optimized for sending notifications to mobile devices.
CoAP Observe
CoAP is an HTTP-compatible, binary protocol deployed over UDP, designed for Internet-of-Things devices. It has support for pushing changes to listening devices with limited processing and memory capability, described in RFC 7641, and may be deployed over WebSockets for use in Web browsers, described in RFC 8323.