@leaflow/sdk 0.0.0-dev.439.g15ccd50 → 0.0.0-dev.443.g1eb982e
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/compute/v2/generated/models.d.ts +37 -0
- package/dist/compute/v2/generated/models.js +5 -0
- package/dist/compute/v2/generated/validators/createElasticIPResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/createInstanceResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/createPrivateImageResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/createVolumeBackupResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/createVolumeResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/createVolumeSnapshotResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/deleteElasticIPResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/deleteInstanceResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/deletePrivateImageResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/deleteVolumeBackupResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/deleteVolumeResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/deleteVolumeSnapshotResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/elasticIP.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/elasticIP.zod.js +4 -0
- package/dist/compute/v2/generated/validators/elasticIPListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/instance.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/instance.zod.js +4 -0
- package/dist/compute/v2/generated/validators/instanceListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/latestOperation.zod.d.ts +46 -0
- package/dist/compute/v2/generated/validators/latestOperation.zod.js +46 -0
- package/dist/compute/v2/generated/validators/networkInterface.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/networkInterface.zod.js +4 -0
- package/dist/compute/v2/generated/validators/networkInterfaceListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/privateImageListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/privateImageResource.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/privateImageResource.zod.js +4 -0
- package/dist/compute/v2/generated/validators/rebuildInstanceResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/rescueInstanceResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/updateElasticIPResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/updateInstanceResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/updateVolumeResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/virtualPrivateCloud.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/virtualPrivateCloud.zod.js +4 -0
- package/dist/compute/v2/generated/validators/virtualPrivateCloudListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/virtualPrivateCloudPeeringListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/virtualPrivateCloudPeeringResource.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/virtualPrivateCloudPeeringResource.zod.js +4 -0
- package/dist/compute/v2/generated/validators/volumeBackupListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/volumeBackupResource.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/volumeBackupResource.zod.js +4 -0
- package/dist/compute/v2/generated/validators/volumeListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/volumeResource.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/volumeResource.zod.js +4 -0
- package/dist/compute/v2/generated/validators/volumeSnapshotListResponseBody.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/volumeSnapshotResource.zod.d.ts +9 -0
- package/dist/compute/v2/generated/validators/volumeSnapshotResource.zod.js +4 -0
- package/dist/eventbus/v1/generated/functions.d.ts +21 -23
- package/dist/eventbus/v1/generated/functions.js +1 -2
- package/dist/eventbus/v1/generated/models.d.ts +53 -40
- package/dist/eventbus/v1/generated/schemas.zod.d.ts +25 -25
- package/dist/eventbus/v1/generated/schemas.zod.js +21 -23
- package/dist/eventbus/v1/generated/validators/createEventRequest.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/createEventRequest.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/createNamespaceRequest.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/createNamespaceRequest.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/createVersionRequest.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/createVersionRequest.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/cursorPagination.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/cursorPagination.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/error.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/error.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/errorStatus.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/errorStatus.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/eventDetail.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/eventDetail.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/eventList.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/eventList.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/eventMessage.zod.d.ts +29 -25
- package/dist/eventbus/v1/generated/validators/eventMessage.zod.js +27 -26
- package/dist/eventbus/v1/generated/validators/eventResource.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/eventResource.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/eventStatus.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/eventStatus.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/eventVersion.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/eventVersion.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/fieldViolation.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/fieldViolation.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/listEventsParams.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/listEventsParams.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/listNamespacesParams.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/listNamespacesParams.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/namespaceList.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/namespaceList.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/namespaceResource.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/namespaceResource.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/namespaceStatus.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/namespaceStatus.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/offsetPagination.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/offsetPagination.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/publication.zod.d.ts +23 -23
- package/dist/eventbus/v1/generated/validators/publication.zod.js +22 -27
- package/dist/eventbus/v1/generated/validators/publicationRecipient.zod.d.ts +89 -0
- package/dist/eventbus/v1/generated/validators/publicationRecipient.zod.js +89 -0
- package/dist/eventbus/v1/generated/validators/publishRequest.zod.d.ts +25 -24
- package/dist/eventbus/v1/generated/validators/publishRequest.zod.js +23 -23
- package/dist/eventbus/v1/generated/validators/publishResponse.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/publishResponse.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/publishedMessage.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/publishedMessage.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/realtimeTicket.zod.d.ts +20 -22
- package/dist/eventbus/v1/generated/validators/realtimeTicket.zod.js +20 -24
- package/dist/eventbus/v1/generated/validators/realtimeTicketRequest.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/realtimeTicketRequest.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/recipient.zod.d.ts +89 -0
- package/dist/eventbus/v1/generated/validators/recipient.zod.js +89 -0
- package/dist/eventbus/v1/generated/validators/sender.zod.d.ts +89 -0
- package/dist/eventbus/v1/generated/validators/sender.zod.js +92 -0
- package/dist/eventbus/v1/generated/validators/updateEventRequest.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/updateEventRequest.zod.js +20 -21
- package/dist/eventbus/v1/generated/validators/updateNamespaceRequest.zod.d.ts +20 -21
- package/dist/eventbus/v1/generated/validators/updateNamespaceRequest.zod.js +20 -21
- package/package.json +1 -1
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|
|
@@ -28,54 +28,53 @@
|
|
|
28
28
|
* wait for consumers. Messages are not stored and are not replayed: a consumer that connects
|
|
29
29
|
* later does not receive earlier messages.
|
|
30
30
|
*
|
|
31
|
-
* Messages published through this API are sent to the current project. A message may name
|
|
32
|
-
* `
|
|
33
|
-
* sent to every member of the project.
|
|
31
|
+
* Messages published through this API are sent to the current project. A message may name a
|
|
32
|
+
* `recipient`, a member of the project; it is then sent to that member only. Without a recipient
|
|
33
|
+
* it is sent to every member of the project.
|
|
34
34
|
*
|
|
35
|
-
* Every
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
39
|
-
*
|
|
35
|
+
* Every message names its `sender`: an `id` and the `name` the publisher had when the message was
|
|
36
|
+
* accepted. A publication may also carry a `client_id`, any label the client chooses, such as one
|
|
37
|
+
* per browser tab. Receivers get it unchanged, so a client can recognise its own messages by
|
|
38
|
+
* `sender` and `client_id`. A client ID need not be unique; a realtime connection is identified
|
|
39
|
+
* by its `connection_id`.
|
|
40
40
|
*
|
|
41
41
|
* ## Realtime
|
|
42
42
|
*
|
|
43
|
-
* Every message has a topic `{event}/{project_id|-}/{
|
|
44
|
-
* for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
43
|
+
* Every message has a topic `{event}/{recipient project_id|-}/{recipient id|-}/{key levels}`, where
|
|
44
|
+
* `-` stands for a missing recipient and the key, split at `/`, supplies the remaining levels. A topic filter
|
|
45
45
|
* uses `+` to match exactly one level and `#`, only as the last level, to match that level and
|
|
46
46
|
* every level below it, including none. For example, `{event}/{project_id}/-/#` matches every
|
|
47
47
|
* message sent to the members of a project, and `{event}/-/{user_id}/#` every message sent to one
|
|
48
48
|
* person outside any project.
|
|
49
49
|
*
|
|
50
50
|
* 1. Create a ticket with `POST /api/v1/realtime/tickets`, naming the events to receive. The
|
|
51
|
-
* response lists the topic filters the ticket covers
|
|
52
|
-
* platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
51
|
+
* response lists the topic filters the ticket covers. For a platform event they cover messages sent to the caller, messages sent to no recipient and,
|
|
53
52
|
* where the caller's permissions allow, messages sent within the project; for a project event
|
|
54
53
|
* they cover messages sent within the project. Without a selected project, use
|
|
55
54
|
* `POST /api/v1/account/realtime/tickets`; such a ticket covers only messages sent to the
|
|
56
55
|
* caller or to no recipient, and cannot publish.
|
|
57
56
|
* 2. Open a WebSocket to `wss://eventbus.leaflow.cloud/realtime` and send, within 15 seconds:
|
|
58
|
-
* `{"type":"authenticate","ticket":"…","client_id":"…"}
|
|
59
|
-
* `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
57
|
+
* `{"type":"authenticate","ticket":"…","client_id":"…"}`, where `client_id` is optional. The
|
|
58
|
+
* reply is `{"type":"authenticated","client_id":"…","connection_id":"…","expires_at":"…"}`.
|
|
60
59
|
* `connection_id` identifies this connection; it is assigned by EventBus and changes on
|
|
61
60
|
* every reconnection.
|
|
62
|
-
* 3.
|
|
61
|
+
* 3. Only after `authenticated`, send `{"type":"subscribe","id":"…","topics":[…]}`; a
|
|
62
|
+
* subscription sent before is rejected. Each topic must be one of the returned
|
|
63
63
|
* `topics` or lie within one of them, for example by naming a key level where the ticket has
|
|
64
64
|
* `#`; a batch with any other topic is rejected as a whole. The reply is `subscribed`.
|
|
65
|
-
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
66
|
-
* while the connection is open.
|
|
65
|
+
* `unsubscribe` takes the same form and replies `unsubscribed`.
|
|
67
66
|
* 4. Messages arrive as `{"type":"messages","messages":[…]}`, each element an `EventMessage`. A
|
|
68
67
|
* message matching several subscriptions on one connection arrives once for each of them.
|
|
69
68
|
* 5. A connection may switch to another ticket of the same user at any time by sending
|
|
70
69
|
* `authenticate` again: to renew before `expires_at`, to move from an account ticket to a
|
|
71
|
-
* project ticket, or to move to another project.
|
|
72
|
-
*
|
|
73
|
-
*
|
|
70
|
+
* project ticket, or to move to another project. Wait for its `authenticated` reply before
|
|
71
|
+
* changing subscriptions; if it is rejected, the previous ticket stays in effect. `client_id`
|
|
72
|
+
* may be omitted to keep the current one. Subscriptions the new ticket does not cover are removed at once and reported in a
|
|
74
73
|
* `{"type":"revoked","topics":[…]}` frame. A ticket for another user closes the connection
|
|
75
74
|
* with code 4401, as does letting the ticket expire.
|
|
76
75
|
*
|
|
77
76
|
* A connection holding a project ticket may publish the project's own events with
|
|
78
|
-
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","
|
|
77
|
+
* `{"type":"publish","id":"…","messages":[{"event":"…","key":"…","recipient":{"id":"…"},"data":{…}}]}`;
|
|
79
78
|
* the reply is `published` with the identity of each message. `ping` is answered with `pong`.
|
|
80
79
|
* A rejected request is answered with `{"type":"error","id":"…","code":"…","message":"…"}`.
|
|
81
80
|
* Every reply carries the `id` of the request it answers.
|