#GlueCon 2014: APIStrat UnWorkshop Notes – Internet of Things

APIStrat UnWorkshop – Internet of Things Why HTTP Won’t Work for IoT – Tim Kellogg @kellogh Embedded + Internet = IoT Constrained environments – memory, embedded linux, No OS, unreliable network connectivity Telemetry – device to server; sensor readings; big data & analytics HTTP is request/response, not pub/sub Consumer must be avail at all times; publisher needs to know exact dest; publisher depends on response status MQTT – broker must be avail at all times; pub/sub decoupled (at leisure); publisher doesn’t care who is subscribed, vice-versa QoS – 3 levels: 0 (fire and forget), 1 (guaranteed delivery at least once), 2 (guaranteed delivery only once) Hierarchy of topics Last value available in case of disconnect MQTT-SN extension for sensor networks w/ UDP and config-free discovery support Constrained Application Protocol (CoAP) HTTP mappings for proxy servers GET+Observe for updates when the resource changes – no polling Book: Mastering the Internet of Things What can you do with connected cars? – Bret Tobey @Carvoyant Big market with complex interfaces reducing developer adoption Lots of opportunity to see how to intersect other APIs, data, and intelligence when we can connect to our cars Many devices are 8-bit, use 2G network w/ UDP, require complex code to fix or integrate Carvoyant tries to normalize across all makes, models, and even differences in the same make/model “Cars drive in realtime, but they weren’t designed to talk in realtime” – on why you can’t sample data every 1 sec, but rather 5 min Greg Burns – Qualcomm AllSeen Alliance – https://allseenalliance.org/ (Chief Architect, working on it for 5 years) – focused on IoT AllJoyn Framework – https://allseenalliance.org/allseen/framework Protocols/interactions different on a private/home network than publishing to cloud where servers might not talk together “Smarthubs” for the home re: rules engines in the home vs. rules engines in cloud services Pushpin & GRIP: next-gen realtime – Justin Fanout.io Passionate about federation and open standards Cloud service for realtime push for API creators with open source server code Scaling realtime push Scaling requires delegation from app to edges to clients Scaling pull traffic is transparent via Varnish, Squid, etc Scaling push traffic has no generalized tools, often proprietary interface, requires engineering to code for it, often by hand Pushpin is the proxy server (aka Varnish for realtime), works for HTTP and websockets w/ full control over client-to-edge interface (to the byte level) Pushpin targets APIs, focused on the backend protocol https://github.com/fanout/pushpin (Mongrel2, 0MQ) Engineers target GRIP protocol, DevOps manages the edges as they see fit Goal is to offer more implementations for Nginx, Apache, etc. Shawn Rose – CIO ecovent Techstars Boston Automated vents that open and close (replaces old metal vents) and sensors to control the temp of each room 4 systems installed w/ -13F and -30% energy use Interact with the NEST API, internal APIs for mobile control How to build APIs for the end user? Canary.io – Open monitoring for the web – http://www.canary.io/ Pat Patterson – Developer Evangelist Architect – Salesforce.com @metadaddy Helping to move medical fridge from a clipboard system of what inventory was removed to an automated system using a barcode reader + smartcard to scan supplies that have been removed, then reported in realtime Do we really need realtime for IoT? Vehicle-to-Vehicle is great but 25 yrs out as it requires a lot of other infrastructure to exist first This is because the IoT has too many variables, both in hardware (the Things part), network (the Internet part), and software (the APIs) Hardware realtime is different than software realtime and each often have different SLAs (tech-driven, not legal/sales-driven) Near-realtime is what people probably mean, not realtime (< 5 ms latency) Devices are limited by battery and compute power to push realtime data This likely means subscriptions are really what are needed, so that interested parties can be informed of events Push is common here for updating web apps without a refresh Realtime definition is relative to the device, app, and end-user and should be specified as benchmarks to clarify intent and staleness Data flow has a distinct impact (device-to-bluetooth-to-mobile, device-to-2G-to-cloud-to-API availability) This means that systems must be designed to be fault-tolerant of missing data Summaries from other groups: Data-driven API design vs. User-experience-driven design Kin sees lots of traffic about API design, markup, and RAML Use the markup that meets your team’s workflow Markup is being driven by auto-generated client and server stubs more than documentation apis.json as a README for APIs (tweeted out) – http://apisjson.org/

James Higginbotham

May 21, 2014 · 4 min read