APIs and Protocols TF
Task force on APIs and Protocols
This task force is (as a draft) chartered to
- landscape architectures, protocols and API patterns and evaluate those based on the collected IoT/WoT use cases
- extract common interaction primitives and define set of abstract interaction primitives for things
- define mappings of the primitives to existing protocols as reference
- define language-independent scripting APIs for both exposing and consuming the primitives as reference
Documents and deliverables
This is a list of documents that are active and archived state.
- Landscaping of relevant technologies - to be merged into the IG document @ new years
- Content to be merged into a new respec doc, ground for guidance: looking for an Editor to provide an initial structure!
- Proposal for a client-side scripting API from FOKUS Link
- Proposed document template for interaction primitives and their mapping to APIs and Protocols Link
- Interaction model and Protocol mappings defined for the WoT Plugfest:
- Resource-oriented Architectures and REST patterns for the Web of Things
- Ari's internet draft "cookbook" https://tools.ietf.org/html/draft-keranen-t2trg-rest-iot-00
- Kazuo-san's slides
- Points raised/resolutions from our Discussion / Breakouts
- Useful to have guidelines for RESTful design to have "less surprises" in the APIs.
- Application state; where is it and how is it modeled. How does the application state related to physical state.
- There are many things in API design that "feel right/wrong". Would be good to have pointers for rationale on such issues in the document.
- The applicability of REST; where does the REST style work well (e.g., resource oriented architectures) and where it is not as good fit (e.g., RPC style actions). How can we extend the applicability and where should we stop and do something else.
- Long running actions and how to interact with them. For example, system can create a new resource for the execution. Should describe these in the draft. Dish-washer program was discussed as an example.
- For partial updates on a resource the PATCH method is useful and should be discussed in this context.
It will start out with weekly calls and relax the schedule to bi-weekly calls when in operation. The meetings will be on Thursdays with rotating times to suit the different time zones
Draft agenda for the next task force call will be posted day-ahead.
Contributions and additions to the agenda are welcome.
The Meetings will be held on webex and be minutes will be scribed in #wot-ap on irc.w3.org.
Minutes of Past Meetings
Use Case mapping to architecture, APIs and protocols
- HTTP (IRTF to provide input)
- HTTP/2 (IRTF to provide input)
- Websocket (Dave Raggett)
- WebRTC (Claes)
- CoAP (Matthias Kovatsch to outreach)
- MQTT (Dave Raggett, Michael Koster)
- addressing scheme is topics
- MQTT is TCP, MQTT SN is UDP
- Pub/sub based, Broker mandatory
- XMPP (Johannes Hund will outreach to XSF)
- AMQP (Dave Raggett to reach out)
- Bluetooth GATT presentation
- remote Key/Value store with CRUD operation
- could be used to model REST with some work
- legacy protocol from WoT perspective
- BLE based protocols: iBeacon, URIBeacon
- UPnP: Universal Plug and Play Protocol (especially UPnP 2.0 with more focus on IoT)
- SSDP: Simple Service Discovery Protocol. SSDP is the discovery layer of UPnP but also used as standalone discovery protocol e.g. in DIAL. (move to DI? -> Soumya)
- mDNS/DNS-SD: multicast DNS based network discovery protocol. Supported on Android and iOS
(move to DI? -> Soumya)
- MMI architecture (Kaz to outreach)
- Thread (Claes)
- Resource Models & Protocol mappings from Consortia (moved to other table)
- CoRE Link format (Soumya presented on July 8)
- link description format
- offers resource type and interface type
- resource type denotes the media type resp. data structure
- interactions of a resource are modeled in the interface type
- OMA LWM2M (Soumya presented on July 8)
- CoAP based device management
- defines resource types for CoRE link
- ISO/IEC/IEEE P21451-1-4
- approach is driven by XMPP
- emphasis on connecting of different (legacy) protocols to/over XMPP transport
- strong security focus (domain federation and identity)
- protocol-agnostic model
Potential scripting API patterns:
Preamble: acknowledge existing web api frameworks. give context, refer to e.g. .
- Client-side APIs
- W3C fetch API
- Presentation API W3C Presentation API (Louay?)
- Geolocation API (Kaz to outreach chair)
- NFC & Bluetooth API (Kaz to outreach)
- scripting APIs to physical things