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"
Hi Paul,

Think of the verbs as telling the client what to do with the topic/payload. GET the resource; PUT the payload; PATCH with the payload. I'm not overly committed to it, but I didn't want to reinvent all the verbage the the PATCH RFC already has.

Many clients can be requesting different content types in HTTP, but for one given topic only _one_ content type will be broadcast because mass confusion. I suggest this should be application/octet-stream which is fairly neutral. However, the Link can explicitly tell the the client what the payload is going to be, e.g.

Link: <tcp://localhost:1883>; rel="mqtt"; payload="PUT"; topic="hello"; content-type="text/plain"

The nice thing about this is if the client doesn't understand the content-type, it can ignore the payload and just use the topic as a trigger for a refetch.

D.




On Mon, Jul 7, 2014 at 5:02 PM, Paul Fremantle <paul.fremantle@xxxxxxxxxx> wrote:
David

Ok. Now I understand.

What I like is your three categories. I'm not sure I like the "overloading" of the verbs. Also, there is a sort of assumption that this is the same content-type, which is generally a good assumption, but that might be another way of specifying which of these three models is in use.

Paul


On 7 July 2014 20:06, David Janes <davidjanes@xxxxxxxxxxxxxx> wrote:
Hi Paul,

This may me being overly clever in naming. 

Here's the scenarios as I envision it for what can be in the payload:
  1. there is never any payload
    this is a pure notification service, when the Client sees the message he should re-query the resource using HTTP. You would advertise this payload type if there's likely to be few interested clients or the payloads are large, say like images
  2. the payload contains the complete resource
  3. the payload contains an _update_ to the resource
Note that the client _always_ has the option of doing an HTTP GET on the original resource, if it's not sure what to do, or it thinks its state is correct, or if it thinks the resource is deleted.

These are all somewhat analogous to HTTP Methods:
  1. GET - i.e. you should call GET to retrieve the resource
  2. PUT - replace the resource
  3. PATCH - here is an update / here is what has changed with the resource (see http://tools.ietf.org/html/rfc5789)
D.


On Mon, Jul 7, 2014 at 4:10 PM, Paul Fremantle <paul.fremantle@xxxxxxxxxx> wrote:
David 

I like this approach. It seems to make some sense to me. I'm not sure about the payload="PUT". Is this something that is mirroring an HTTP approach?

Paul


On 7 July 2014 12:50, David Janes <davidjanes@xxxxxxxxxxxxxx> wrote:
Specifically for Ponte, which I just downloaded, if this resource


Returned the header:

Link: <tcp://localhost:1883>; rel="mqtt"; payload="PUT"; topic="hello"

Then clients that knew about rel="mqtt" would automatically know:
  • MQTT is available
  • it's at localhost:1883
  • the topic of updates is "hello"
  • the full updated resource is available  (payload="PUT")
What's beautiful about this is the It Just Works nature. Smart clients - assuming uptake of this idea - don't need to read the docs to figure out how to know if the resource they're querying is getting updates.

** Note ** : I'm going to change the spec I've written to assume the content-type is application/octet-stream.

Regards,
D.



On Mon, Jul 7, 2014 at 7:30 AM, David Janes <davidjanes@xxxxxxxxxxxxxx> wrote:
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.

D.



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, http://eclipse.org/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.

Cheers,

Matteo

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev



_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev



--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev



--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

Back to the top