wsa 1.0.4

WebSocket-based API protocol.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161

# WSA
### WebSocket API Spec

**This document defines the specification for a WebSocket-based API protocol. It applies to production environments, using compressed formats.**

## From

- Must be either `"server"` or a specific `client_id`
- If `from` is `server`, it's the only global server
- If not, it **must** be a valid `client_id`

## To

- Can be:

  - `"server"`: for messages directed to the server
  - `"client_id"`: when directed from a client to another client (via server proxy)
  - `"client"`: broadcast message to all clients (only allowed **from server**)

### Rules

- `client` can be the target (`to`) if the message originates from the `server`, or is routed **via** the server from another client
- A client **may send** a message with `to: "client"`, but it **must** be relayed through the server, which will handle authentication and authorization.

## Type

Only three values are allowed:

- `"request"`
- `"response"`
- `"event"`

## ID

- Message `id` is chosen by the sender
- It should be the ISO8601 timestamp at the moment of sending, e.g.: 

  ```
  "2025-05-14T11:27:31.536370717+08:00"
  ```

**This feature may be cancelled in the next version. At that time, it will be changed to a string of [a-z0-9]{5}, msg_id.**

- For `response` type messages:

  - `id` **must match** the original `request` or `event` message's ID
  - `response` messages **must not** use a new unique ID

## Request Message Structure

```json
{
  "from": "",
  "to": "",
  "type": "request",
  "id": "",
  "payload": {
    "method": "auth@v1/login",
    "params": {}
  }
}
```

- `method`: target service and versioned endpoint (e.g. `auth@v1/login`)
- `params`: arguments passed to backend service function

## Response Message Structure

```json
{
  "from": "",
  "to": "",
  "type": "response",
  "id": "",
  "payload": {
    "result": "success",
    "receipt": "optional_id_or_null"
  }
}
```

```json
{
  "from": "",
  "to": "",
  "type": "response",
  "id": "",
  "payload": {
    "result": "fail",
    "code": "PERMISSION_DENIED"
  }
}
```

## Event Message Structure

```json
{
  "from": "",
  "to": "",
  "type": "event",
  "id": "",
  "payload": {
    "method": "chat@v1/message",
    "params": {}
  }
}
```

---

# Production Format (Compressed)

## Message Structure

```json
{
  "f": "s",
  "t": "",
  "y": "g",
  "i": "abc12",
  "P": {}
}
```

### Payload for Request/Event

```json
{
  "p": {
    "m": "auth@v1/login",
    "p": ["arg1", "arg2"]
  }
}
```

### Payload for Successful Response

```json
{
  "p": {
    "r": "s",
    "c": "resource_id"
  }
}
```

### Payload for Failure Response

```json
{
  "p": {
    "r": "f",
    "c": "PERMISSION_DENIED"
  }
}
```

---

This format is optimized for bandwidth-sensitive environments by shortening keys and values. It is strongly recommended to use the verbose version during development and the compact version in production deployments.