7 years, 6 months ago.

Pull mbed Device Connector Resource Observations - without Webhooks (Push)

Based on my current understanding, I need to subscribe to a resource in order to get notifications of changes from those resources through Webhooks ... this PUSH approach seams ok, if the resources change rather infrequently ... and I have a couple of devices in the field ...

If I am thinking about 1000s of devices with frequent delivery of changes this approach looks rather inefficient.

I would like to understand, if I can subscribe to resources, but directly access the (asynchronous) notifications of resources through the Rest Interface (PULL) of mbed Device Connector (without using Webhooks) - in order to stream the data e.g. into Apache Kafka for persistence and further processing.

1 Answer

7 years, 6 months ago.

Hi Rainer,

You sure can! mbed Device Connector supports long polling: https://docs.mbed.com/docs/mbed-device-connector-web-interfaces/en/latest/api-reference/#long-polling

Also be sure to check out the main mbed Device Connector Web Interfaces guide here: https://docs.mbed.com/docs/mbed-device-connector-web-interfaces/en/latest/. It talks a bit about long polling and notifications in general.

Hope that helps!

-Brian

Also, we've made some web libraries to make using mbed Device Connector even easier.

We have a Node.js library here: https://github.com/ARMmbed/mbed-connector-api-node

And a Python library here: https://github.com/ARMmbed/mbed-connector-api-python

posted by Brian Daniels 30 Sep 2016

Hi Brian,

thanks for feedback. I am aware of the outlined resources, and I was already playing around with mbed Client Java webapp outlined here: https://github.com/ARMmbed/mbed-webapp-example/.

Based on what I can see is that for long polling the app always reopens the connection after 25s with a "https://api.connector.mbed.com:443/v2/notification/pull"

In the mbed device connector api reference there is the following note:

It is mandatory to create a persistent connection, by sending the Connection: keep-alive header, to avoid excessive TLS handshakes

whenever I use curl though with

curl -s -H 'Connection: keep-alive' -H 'Authorization: Bearer <myBearer>' https://api.connector.mbed.com/v2/notification/pull

the commend breaks after the first notification.

Can you please elaborate on how I am getting a constant stream of events and keep the curl alive?

posted by Rainer Geissendoerfer 02 Oct 2016

Hi Rainer,

Thanks for elaborating a bit on your question, I think I may have been a bit eager in my answer :)

If I understand your question now, it sounds like what you're asking for is something closer to a WebSocket connection? Where the connection is persistent but the data comes in as it's available? To my knowledge this kind of support does not exist in mbed Device Connector.

If I misunderstood your question (again!), would you mind clarifying a bit more?

Thanks,

Brian

posted by Brian Daniels 02 Oct 2016

Hi Brian,

thanks again for your feedback ...

Yes, I strongly believe that Device Connector has to deliver the incoming events either through

1) Server Sent Events (prefered) or

2) Websockets

If neither of this capabilities are available, then I don't see any commercial usage of Device Connector due to the overhead generated by the provided long polling and web hooks alternatives.

A good example on how this should work is particles "Device Connector" https://docs.particle.io/reference/api/#get-a-stream-of-your-events through Server Sent Events.

Is there a roadmap of mbed device connector where I can see what's coming in regards to functionality so I can adjust my plans accordingly?

posted by Rainer Geissendoerfer 03 Oct 2016

Hi Rainer,

Thanks for your feedback on Device Connector, I've passed it on to the Device Connector team!

I'm not aware of a roadmap that has been released for mbed Device Connector, but if I find one I'll try to post it here.

Thanks,

Brian

posted by Brian Daniels 04 Oct 2016