Why use websockets?
Why Blazeauth uses a persistent WebSocket protocol and how it differs from REST for this API.
Blazeauth uses WebSocket as the primary API transport because most operations benefit from a long-lived, stateful connection.
WebSocket vs REST in Blazeauth context
| Area | WebSocket approach (Blazeauth) | Typical REST approach |
|---|---|---|
| Connection model | One persistent connection | Many short-lived HTTP requests |
| State handling | Session context is kept server-side between packets | Context often rebuilt or revalidated per request |
| Server push | Native, same channel as requests | Requires polling, long-polling, or extra channels |
| File transfer | Native binary frames in same protocol | Separate upload/download endpoints and flow |
| Reconnect behavior | Supports session resumption by Resume-Id | Usually client retries with partial stateless recovery |
Practical benefits for your client
- Lower latency for multi-step auth/licensing flows.
- Less protocol overhead for frequent small operations.
- Real-time panel events without polling.
- Consistent request/response contract with packet IDs.
- One protocol for control operations and binary payload delivery.
When REST can still make sense
- Public, cacheable, read-heavy endpoints.
- Integrations where realtime delivery is not required.
- Environments where persistent connections are restricted by infrastructure.