WebSocket Protocol Structure

The WebSocket protocol structure will mimic, as far as possible, the RESTful calls. All exchanged messages will be JSON-encoded structures. Where response codes are needed, a field will contain the same HTTP response code as returned by the RESTful API. Any data that are supplied via HTTP headers in the RESTful API will have corresponding identical (or, where this is not possible, similarly) named JSON properties. Likewise RESTful actions (GET, POST, PUT) will be mimic'd using a JSON property whose schema is an enumeration of those action values.

Message Identifiers

Request and response correlation will be achieved using per-session message identifiers. Since WebSocket communications are asynchronous, the direct correlation of reading a response for a request does not exist, any inbound message to a client could be a response for any previously received message from that client, or it could be an out-of-order notification (such as VAD). A client will be required to maintain some repository of unique message identifiers, assigning an ID to a request it sends in to the server. That ID will be echoed in the response so that the client can correlate the request and response. An example of such an ID repository might be a monotonically increasing sequence number. This protocol will not enforce any particular message ID structure beyond specifying that within a single WebSocket session between the client and server, the assigned message ID must be unique.

Text and Binary Messages

WebSockets supports two types of messages: text and binary. This protocol distinguishes between the two, relying on all JSON-encoded protocol messages being delivered as text messages. The binary messaging endpoint is reserved for sending the audio data exclusively.