Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Binding MQTT to REST servers using Link: rel="mqtt"

I've modified the docs to back off a little on REST and more clearly state "notifications about changes to a resource".

I'm not sure if I follow that getting notifications to a REST resource is a dead end - or is it only a dead end because of the nature of MQTT? For example, if you consider a Facebook conversation a resource (this is reasonable), updates to the conversation are being usefully broadcast and received using MQTT. The only client that's disadvantaged by the scheme I'm proposing is one that would have been doing polling before but is depending on an unreliable broker.

Is this not a natural fit for Ponte? I.e. the HTTP API can inform it's clients that MQTT updates on the given Resource are being made available at a particular broker on a particular topic?


As an aside, I've actually been doing quite a bit of work on the "toggle the light" vs "turn the light on", specifically in the context of IOTDB.  I have quite the IoT workshop at home!. Note that IOTDB's primary goal is to _describe_ how things work, not a prescription of how things should work.

Even something as simple as turning a light on and off gets quite complicated:

* some devices only provide toggles, i.e. TV sets for turning on/off via IR
* if you're monitoring "is the light on/off" using the same variable as "send a commend to turn the light on/off" you're in for a lot of pain
* if you use the same variable for "send the command turn the light/on off" as "I have _sent_ the command to turn the light on/off" (and therefore I don't need to send it again) you can end up with situations where you can't control things anymore because it thinks it's already in the state you want to send.


On Mon, Jul 7, 2014 at 2:35 AM, Matteo Collina <hello@xxxxxxxxxxxxxxxxx> wrote:
Hi David,

I think it's not really possible to have pseudo real-time notifications in REST. The protocol is built with a request/response semantic, plus it's key feature is caching. To my understanding, trying to follow pseudo real-time in REST is a dead end. However, my REST (HTTP/CoAP) <-> MQTT bridge (Ponte, works very well in this scenario by acknowledging this very same fact.

MQTT has a key feature in retained messages. A very basic key-value store that allows you to store a value for each topic. If you just limit the REST API to the retained messages, you have the same basic semantic of a REST endpoint, and you can map them just fine. One caveat: you should not send commands 'toggle the light', but states 'the light is on'. Otherwise duplicated commands can lead to unexpected results. Let me know if you have more questions on this one. We might even join forces on this, Ponte is based on node.js so you might even reuse that for iotdb. Let me know :).

Anyway, good idea having a link header for MQTT topics, I think we should standardize that.



paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top