RoboMQ, Internet ofThings (IoT) middleware platform is built ground up to allow collaboration and data interchange between any device to any system, cloud or thing. It has a rich set of connectors and adapters to allow this promise. These set of connectors and adapter are collectively part of “ThingsConnect” suite.
We recently released for GA (General Availability), the REST adapter for RoboMQ. REST is a common architectural style for exposing the application services over HTTP/HTTPS. It follows the basic model of how web works and supports operations to retrieve or modify objects identified as URI resource. We all are familiar with the operation like GET for reading an object and POST for creating an object. The beauty of REST is the simplicity, the convenience and the wide support it has across all platforms, programming languages and SaaS and mobile applications.
So what does it mean for you? Quite simply you can integrate the device and sensors a.k.a. “things” to your applications using the very familiar and widely available REST interfaces that you may already be using.
How does it work? We know that the RoboMQ is a message-oriented middleware for IoT and application integration. There are numerous benefits of a Message Oriented Middleware (MOM), the primary ones being the reliable and guaranteed delivery and the ability to develop decoupled applications. The decoupling allows faster time to market (TTM), lower cost of development and ability to plug and play components allowing future proofing and flexibility to change as the needs and the business conditions change. You can learn more about these benefits at our readthedocs page.
With the messaging systems, you can either get (read) a message or publish (write) a message. It is that simple and this simplicity is reason behind the benefits that it offers. REST works in a vey similar style as well. For any resource, you can read it by GET operation on the resource. You can create or write a new resource by using the familiar POST operations. We have basically mapped the REST GET operation to getting a message and the POST operation to publishing a message. It’s that simple!!
You must be thinking – Ok, I get the mapping of the operations, but how do you identify a resource much the way we are used to doing it using the URI in REST? Just as in messaging you read or write to a queue (or to be technically correct, route a message to a queue). The resource identification is at the queue level. A URI consists of the exchange name, queue name and the routing key which is used to identify a unique destination from which a to GET or POST a message.
|Schematic of REST operations on RoboMQ|
To summarize the operations of the RoboMQ REST adapter:
HTTP GET operation: read the message from a queue identified by its URI.
GET operation will read exactly one message if available from the Queue, much like the read from a Queue using any of the messaging protocols like MQTT, AMQP, Stomp, WebSTOMP etc.
HTTP POST operation: publish a message to a destination identified by its URI.
POST operation will publish the message at the exchange with a routing key. The RoboMQ platform will deliver the message to the recipient who has subscribed to these messages based on the routing key.
And did I tell you; you are not restricted to sending and receiving a message in REST, or for that matter in any of the protocols. RoboMQ supports full cross protocol conversion. You can send a message in REST and receive it using any of the protocols like MQTT, Stomp, WebSTOMP or AMQP and vice-versa.