As you dive into the world of connected products, one of the most basic components you will have to choose is your message broker. The broker is the component of your system that takes messages from the various devices, users, and apps in your system, and makes sure that they get to their intended recipients quickly, scalably, securely and with guaranteed reliability of the delivery. If you’re curious what comes the next component you’ll need to decide on, it’s an authorization framework on top of that broker that will control exactly who is allowed to send messages to whom! But let’s not get ahead of ourselves.
Xively’s connected product messaging broker is built on the lightweight, powerful and scalable MQTT message protocol (which recently became an ISO standard ) This protocol is built for guaranteed-delivery message distribution at very high scale, using lightweight packets to make message delivery possible even with limited network bandwidth.
However, in addition to the MQTT protocol, today we are happy to announce HTTP support on our broker . Now devices, users and apps can use an HTTP POST to make the equivalent of a “PUB” in MQTT.
What is really exciting about the addition of HTTP support, is that it is fully interoperable with the broker’s other methods (see below for all of them). This means that you can have a device subscribed to an MQTT topic, and send a message to it by simply making an HTTP POST from your application. This shows Xively’s continued dedication to helping customers get to market faster and flexibly.
HTTP communication is more common than MQTT on the web, and in many cases it’s much easier to get started/start prototyping. This capability lets you:
- Rapidly prototype message sending from many common REST clients before implementing in MQTT
- Send messages from devices (especially ones with resources), that cannot support an MQTT client
- Give customers or partners quick integration methods through HTTP APIs, even if your devices and apps are using MQTT connectivity
- Send messages over networks which (for security, IT or a variety of other use-case specific reasons) have blocked MQTT traffic
As always, these endpoints are held to the strictest security standards, and as such all communication to and from Xively must be encrypted. The new HTTP support is no exception, all HTTP requests must use TLS (HTTPS) and target port 443.
This now brings the number of communication methods to the Xively broker up to 3:
- Native MQTT (Secure Ports 8883 and 443)
- Useful when a client has an MQTT library that supports native connections
- Preferred method of connection for scalability and distributed message delivery
- MQTT over WebSockets (Secure Port 443
- Useful when a client does not support native MQTT connections (such as a web browser
- Requires an MQTT client with WebSockets support
- HTTP Rest API (Secure Port 443
- Useful when a client does not have MQTT, or does not want to use MQTT
- Can be used for publish only
Have questions? Want to get started? Get in touch!