Websockets over HTTP

Ironbeam API
1

Hello,
Just thought I’d write this in as a general inquiry/idea. I am not too familiar with MQTT at this point but I was wondering if Ironbeam API ever plans to consider implementing a HTTP based Websocket protocol. This is pretty much the standard I’ve seen, especially in the crypto space. Here is an example of Kucoin exchange: KuCoin API Documentation
Binance also uses the HTTP based Websocket protocol.

Maybe I am misunderstanding how the MQTT Websocket protocol works but to me it sounds like a different protocol than the HTTP one. The HTTP method in my opinion is simpler and there is more widespread documentation and implementations of HTTP/Websocket in multiple languages. It could attract more developers to Ironbeam API.

1 Like
2

Hey @vt_trader01

Thank you for your feedback.

In short, yes, we’re actively working on introducing a REST API soon, recognizing its widespread popularity. To address your query about MQTT vs. HTTP-based Websockets, here’s a succinct breakdown:

REST (HTTP-based Websocket) Advantages:

  1. Widespread Use: Common in many platforms, especially in the crypto sector, with abundant documentation and libraries.
  2. Stateless: Each request contains all necessary information, simplifying certain development aspects.
  3. Human-readable: Typically employs JSON, which is developer-friendly.

MQTT Advantages for Futures Trading:

  1. Low Bandwidth: Designed for minimal bandwidth consumption, offering swift data transmissions.
  2. Real-time: The publish/subscribe model is perfect for immediate updates—a necessity in futures trading.
  3. Persistent Sessions: Enables continuation without re-subscribing, which can be beneficial for tracking futures positions over time.
  4. Quality of Service: Multiple levels ensure message delivery reliability, critical for trade commands.
  5. Durable Connections: Designed for environments where the connection might be unstable, ensuring that trade data isn’t lost.
  6. Scalability: Can handle a large number of devices or trading bots, ideal for larger scale trading operations.

REST Limitations:

  1. Stateless Constraints: For intricate trading operations, state management might be vital, which REST isn’t inherently designed for.
  2. Potential Overhead: Can be verbose, especially if polling data frequently.

MQTT Limitations:

  1. Steep Learning Curve: Not as universally known as REST.
  2. Less Web-Native: Being a distinct protocol, may not be as web-ready as HTTP/Websocket.

Both protocols have their merits, and the choice often boils down to the specific needs of the trading operation. We appreciate your insights and will keep our users informed about future updates.

Mike Murphy
[email protected]

2 Likes