diff options
Diffstat (limited to 'docs/api/events.md')
| -rw-r--r-- | docs/api/events.md | 145 |
1 files changed, 79 insertions, 66 deletions
diff --git a/docs/api/events.md b/docs/api/events.md index b23469c..3347a26 100644 --- a/docs/api/events.md +++ b/docs/api/events.md @@ -28,12 +28,14 @@ sequenceDiagram end ``` -The core of the service is to facilitate conversations between logins. Conversational activity is delivered to clients using _events_. Each event notifies interested clients of activity sent to the service through its API. +The core of the service is to facilitate conversations between users. Conversational activity is delivered to clients using +_events_. Each event notifies interested clients of activity sent to the service through its API. ## Asynchronous completion -A number of endpoints return `202 Accepted` responses. The actions performed by those endpoints will be completed before events are delivered. To await the completion of an operation which returns this response, clients must monitor the event stream for the corresponding event. +A number of endpoints return +`202 Accepted` responses. The actions performed by those endpoints will be completed before events are delivered. To await the completion of an operation which returns this response, clients must monitor the event stream for the corresponding event. ## `GET /api/events` @@ -46,11 +48,14 @@ This endpoint is designed for use with the [EventSource] DOM API, and supports s ### Query parameters -This endpoint requires a `resume_point` (integer) query parameter. The event stream will collect events published after that point in time. The value must be obtained by calling the [`GET /api/boot`](./boot.md) method. +This endpoint requires a +`resume_point` (integer) query parameter. The event stream will collect events published after that point in time. The value must be obtained by calling the [ +`GET /api/boot`](./boot.md) method. ### Request headers -This endpoint accepts an optional `last-event-id` (string) header. If present, the value must be the value of the `id` field of the last message processed by the client. The returned event stream will begin with the following message. If absent, the returned event stream will begin from the start of the event collection. +This endpoint accepts an optional `last-event-id` (string) header. If present, the value must be the value of the +`id` field of the last message processed by the client. The returned event stream will begin with the following message. If absent, the returned event stream will begin from the start of the event collection. This header is set automatically by `EventSource` when reconnecting to an event stream. @@ -67,7 +72,7 @@ data: "type": "message", data: "event": "sent", data: "at": "2024-09-27T23:19:10.208147Z", data: "channel": "C9876cyyz", -data: "sender": "L1234abcd", +data: "sender": "U1234abcd", data: "id": "M1312acab", data: "body": "beep" data: } @@ -75,46 +80,47 @@ data: } The service will keep the connection open, and will deliver events as they occur. -The service may terminate the connection at any time. Clients should reconnect and resume the stream, using the `last-event-id` header to resume from the last message received. The `id` of each event is an ephemeral ID, useful only for this purpose. +The service may terminate the connection at any time. Clients should reconnect and resume the stream, using the +`last-event-id` header to resume from the last message received. The +`id` of each event is an ephemeral ID, useful only for this purpose. Each event's `data` consists of a JSON object describing one event. Every event includes the following fields: -| Field | Type | Description | -|:--------|:-------|:--| -| `type` | string | The type of entity the event describes. Will be one of the types listed in the next section. | +| Field | Type | Description | +|:--------|:-------|:-------------------------------------------------------------------------------------------------------------| +| `type` | string | The type of entity the event describes. Will be one of the types listed in the next section. | | `event` | string | The specific kind of event. Will be one of the events listed with the associated `type` in the next section. | The remaining fields depend on the `type` and `event` field. -## Login events +## User events -The following events describe changes to logins. +The following events describe changes to users. -These events have the `type` field set to `"login"`. +These events have the `type` field set to `"user"`. -### Login created +### User created ```json { - "type": "login", - "event": "created", - "at": "2024-09-27T23:17:10.208147Z", - "id": "L1234abcd", - "name": "example username" + "type": "user", + "event": "created", + "at": "2024-09-27T23:17:10.208147Z", + "id": "U1234abcd", + "name": "example username" } ``` -Sent whenever a new login is created. +Sent whenever a new user is created. These events have the `event` field set to `"created"`. They include the following additional fields: -| Field | Type | Description | -|:-------|:----------|:--| -| `at` | timestamp | The moment the login was created. | -| `id` | string | A unique identifier for the newly-created login. This can be used to associate the login with other events, or to make API calls targeting the login. | -| `name` | string | The login's name. | - +| Field | Type | Description | +|:-------|:----------|:---------------------------------------------------------------------------------------------------------------------------------------------------| +| `at` | timestamp | The moment the user was created. | +| `id` | string | A unique identifier for the newly-created user. This can be used to associate the user with other events, or to make API calls targeting the user. | +| `name` | string | The user's name. | ## Channel events @@ -126,11 +132,11 @@ These events have the `type` field set to `"channel"`. ```json { - "type": "channel", - "event": "created", - "at": "2024-09-27T23:18:10.208147Z", - "id": "C9876cyyz", - "name": "example channel 2" + "type": "channel", + "event": "created", + "at": "2024-09-27T23:18:10.208147Z", + "id": "C9876cyyz", + "name": "example channel 2" } ``` @@ -138,14 +144,18 @@ Sent whenever a new channel is created. These events have the `event` field set to `"created"`. They include the following additional fields: -| Field | Type | Description | -|:-------------|:--------------------|:--| -| `at` | timestamp | The moment the channel was created. | +| Field | Type | Description | +|:-------------|:--------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `at` | timestamp | The moment the channel was created. | | `id` | string | A unique identifier for the newly-created channel. This can be used to associate the channel with other events, or to make API calls targeting the channel. | -| `name` | string | The channel's name. | -| `deleted_at` | timestamp, optional | If set, the moment the channel was deleted. | +| `name` | string | The channel's name. | +| `deleted_at` | timestamp, optional | If set, the moment the channel was deleted. | -When a channel is deleted or expires, the `"created"` event is replaced with a tombstone `"created"` event, so that the original channel cannot be trivially recovered from the event stream. Tombstone events have a `deleted_at` field, and a `name` of `""`. Tombstone events for channels use an empty string as the name, and not `null` or with the `name` field removed entirely, to simplify client development. While clients _should_ treat deleted channels specially, for example by rendering them as "channel deleted" markers, they don't have to be - they make sense if interpreted as channels with empty names, too. +When a channel is deleted or expires, the `"created"` event is replaced with a tombstone +`"created"` event, so that the original channel cannot be trivially recovered from the event stream. Tombstone events have a +`deleted_at` field, and a `name` of `""`. Tombstone events for channels use an empty string as the name, and not +`null` or with the `name` field removed entirely, to simplify client development. While clients +_should_ treat deleted channels specially, for example by rendering them as "channel deleted" markers, they don't have to be - they make sense if interpreted as channels with empty names, too. Once a deleted channel is [purged](./channels-messages.md#expiry-and-purging), these tombstone events are removed from the event stream. @@ -153,10 +163,10 @@ Once a deleted channel is [purged](./channels-messages.md#expiry-and-purging), t ```json { - "type": "channel", - "event": "deleted", - "at": "2024-09-28T03:40:25.384318Z", - "id": "C9876cyyz" + "type": "channel", + "event": "deleted", + "at": "2024-09-28T03:40:25.384318Z", + "id": "C9876cyyz" } ``` @@ -164,11 +174,10 @@ Sent whenever a channel is deleted or expires. These events have the `event` field set to `"deleted"`. They include the following additional fields: -| Field | Type | Description | -|:------|:----------|:--| +| Field | Type | Description | +|:------|:----------|:------------------------------------| | `at` | timestamp | The moment the channel was deleted. | -| `id` | string | The deleted channel's ID. | - +| `id` | string | The deleted channel's ID. | ## Message events @@ -180,13 +189,13 @@ These events have the `type` field set to `"message"`. ```json { - "type": "message", - "event": "sent", - "at": "2024-09-27T23:19:10.208147Z", - "channel": "C9876cyyz", - "sender": "L1234abcd", - "id": "M1312acab", - "body": "an effusive blob of prose, condensed down to a single string" + "type": "message", + "event": "sent", + "at": "2024-09-27T23:19:10.208147Z", + "channel": "C9876cyyz", + "sender": "U1234abcd", + "id": "M1312acab", + "body": "an effusive blob of prose, condensed down to a single string" } ``` @@ -194,16 +203,20 @@ Sent whenever a message is sent by a client. These events have the `event` field set to `"sent"`. They include the following additional fields: -| Field | Type | Description | -|:-------------|:--------------------|:--| -| `at` | timestamp | The moment the message was sent. | -| `channel` | string | The ID of the channel the message was sent to. | -| `sender` | string | The ID of the login that sent the message. | +| Field | Type | Description | +|:-------------|:--------------------|:----------------------------------------------------------------------------------------------------------------------------------------------| +| `at` | timestamp | The moment the message was sent. | +| `channel` | string | The ID of the channel the message was sent to. | +| `sender` | string | The ID of the user that sent the message. | | `id` | string | A unique identifier for the message. This can be used to associate the message with other events, or to make API calls targeting the message. | -| `body` | string | The text of the message. | -| `deleted_at` | timestamp, optional | If set, the moment the message was deleted. | +| `body` | string | The text of the message. | +| `deleted_at` | timestamp, optional | If set, the moment the message was deleted. | -When a message is deleted or expires, the `"sent"` event is replaced with a tombstone `"sent"` event, so that the original message cannot be trivially recovered from the event stream. Tombstone events have a `deleted_at` field, and a `body` of `""`. Tombstone events for messages use an empty string as the `body`, and not `null` or with the `body` field removed entirely, to simplify client development. While clients _should_ treat deleted messages specially, for example by rendering them as "message deleted" markers, they don't have to be - they make sense if interpreted as messages with empty bodies, too. +When a message is deleted or expires, the `"sent"` event is replaced with a tombstone +`"sent"` event, so that the original message cannot be trivially recovered from the event stream. Tombstone events have a +`deleted_at` field, and a `body` of `""`. Tombstone events for messages use an empty string as the `body`, and not +`null` or with the `body` field removed entirely, to simplify client development. While clients +_should_ treat deleted messages specially, for example by rendering them as "message deleted" markers, they don't have to be - they make sense if interpreted as messages with empty bodies, too. Once a deleted message is [purged](./channels-messages.md#expiry-and-purging), these tombstone events are removed from the event stream. @@ -211,10 +224,10 @@ Once a deleted message is [purged](./channels-messages.md#expiry-and-purging), t ```json { - "type": "message", - "event": "deleted", - "at": "2024-09-28T02:44:27.077355Z", - "id": "M1312acab" + "type": "message", + "event": "deleted", + "at": "2024-09-28T02:44:27.077355Z", + "id": "M1312acab" } ``` @@ -222,7 +235,7 @@ Sent whenever a message is deleted or expires. These events have the `event` field set to `"deleted"`. They include the following additional fields: -| Field | Type | Description | -|:------|:----------|:--| +| Field | Type | Description | +|:------|:----------|:------------------------------------| | `at` | timestamp | The moment the message was deleted. | -| `id` | string | The deleted message's ID. | +| `id` | string | The deleted message's ID. | |