Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
developers:websocket [2025/03/14 03:02] – external edit 127.0.0.1 | developers:websocket [2025/03/14 19:15] (current) – [Message Structure Overview] chad | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Getting Started ====== | + | ===== WebSocket API Introduction |
- | To begin integrating, visit the [[getting_started|Getting Started]] guide for **connection | + | The WebSocket API provides a high-performance, low-latency communication channel for real-time trading data and order execution. This section introduces |
+ | |||
+ | ==== WebSockets ==== | ||
+ | WebSockets establish a persistent, full-duplex connection between the client and server, allowing | ||
+ | |||
+ | **Key Advantages: | ||
+ | * Persistent | ||
+ | * Low-latency, real-time data exchange | ||
+ | * Efficient bandwidth usage compared to REST APIs | ||
+ | |||
+ | ==== Google Protocol Buffers (Protobuf) ==== | ||
+ | The API utilizes Protobuf for efficient, compact, and high-speed message serialization. Unlike JSON or XML, Protobuf messages are smaller and faster to parse, making them well-suited for high-frequency trading applications. | ||
+ | |||
+ | **Why Protobuf? | ||
+ | * **Compact Encoding:** Reduces message size for faster transmission | ||
+ | * **High Performance: | ||
+ | * **Schema Evolution: | ||
+ | |||
+ | ==== Communication Model ==== | ||
+ | The API follows a structured messaging approach: | ||
+ | * **Client Messages:** Requests sent from clients to the server (e.g., order submission, subscription requests) | ||
+ | * **Server Messages:** Responses and real-time updates sent from the server (e.g., trade confirmations, | ||
+ | |||
+ | ==== Message Structure Overview ==== | ||
+ | |||
+ | All messages sent to the server must be wrapped in a **ClientMessage** envelope, and all messages received from the server will be contained within a **ServerMessage** envelope. This ensures a consistent structure and simplifies message parsing. | ||
+ | |||
+ | === Client Message Structure === | ||
+ | |||
+ | A **ClientMessage** is the top-level wrapper for all messages sent to the server. It contains fields for various message types, such as authentication | ||
+ | |||
+ | Example | ||
+ | |||
+ | < | ||
+ | message ClientMessage { | ||
+ | oneof payload { | ||
+ | AuthenticationRequest authentication_request = 1; | ||
+ | MarketSubscription market_subscription = 2; | ||
+ | OrderRequest order_request = 3; | ||
+ | // ... other client messages | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | === Server Message Structure === | ||
+ | |||
+ | A **ServerMessage** is the top-level wrapper for all responses and updates from the server. It encapsulates messages related to market data, account updates, and execution reports. | ||
+ | |||
+ | Example **ServerMessage**: | ||
+ | |||
+ | < | ||
+ | message ServerMessage { | ||
+ | oneof payload { | ||
+ | AuthenticationResponse authentication_response = 1; | ||
+ | MarketSnapshot market_snapshot = 2; | ||
+ | OrderUpdate order_update = 3; | ||
+ | // ... other server messages | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | |||
+ | === Message Tools === | ||
+ | |||
+ | The [[https:// | ||
+ | |||
+ | < | ||
+ | Reach out to support if you would like a API tool's for a language we have not covered yet. | ||
+ | </ | ||
+ | |||
+ | ^ **Platform** ^ **Client Message Helper** ^ | ||
+ | | **.Net** | [[https:// | ||
- | For a detailed breakdown of all available messages, see the [[message_reference|Message Reference]]. | ||
- | ---- | ||
- | 💡 **Tip:** Use WebSocket clients like `wscat` or our sample SDKs to test the API before building your integration. | ||
- | ===== Next Steps ===== | ||
- | * Connect and Authenticate to **market data streams** ([[api: | ||