REST
APIs
for
the
Internet
Of
Things
Michael
J
Koster
Open
Source
Internet
Of
Things
Meetup
19
March
2014
Resource
oriented
API
• Resource
==
web
resource
(URI)
• Resources
change
state
in
response
to
what
is
being
sensed
• Actuator
changes
state
in
response
to
web
resource
update
• Abstract
data
sources
and
sinks
• REST
API
has
2
important
characterisJcs
for
IoT
use
case…
RepresentaJonal
State
Transfer
• Resource
interacJon
through
exchange
of
representaJon
of
resource
state
• E.g.
a
representaJon
of
the
state
of
a
temperature
sensor
might
be
“63.6”
• Convenient
for
applicaJon
soTware
to
use
read/write
semanJcs
to
interact
with
resources
• Stateful
resource
representaJons
=>
Stateless
applicaJon
soTware
Based
on
Hypermedia
• Use
of
web
links
to
locate
resources
of
interest
• IoT
needs
machine-‐readable
links
that
enable
applicaJon
soTware
to
discover
things
of
interest
• Subset
of
web
linking,
semanJc
web
using
relaJon/aribute
• Links
encode
metadata
about
the
resource,
e.g.
type=‘temperature’,
ct=‘applicaJon/json’
Web
Linking
for
IoT
• Links
are
managed
in
2
ways
• Object
encapsulaJon:
self-‐describing
objects
have
links
associated
with
endpoint,
e.g.
./
well-‐known/core
• Resource
Directory:
Directories
and
Catalogs
of
links,
stored
at
well-‐known
locaJons,
that
point
to
resources
and
to
other
catalogs
Web
Linking
for
IoT
• Links
can
be
registered
with
a
Resource
Directory
when
sensors
are
brought
online
• A
crawler
can
discover
links
at
./well-‐known/core
locaJons
and
populate
catalogs
• ApplicaJon
soTware
can
discover
resources
by
aribute,
e.g.
query
using
type=‘temperature’,
units=‘celsius’,
locaJon=‘outdoor’
etc.
• System
returns
a
set
of
links
matching
the
query
aributes
CoAP
• Part
of
IPV6
for
Constrained
Resource
Environments
(CoRE)
• IoT
oriented
REST
API
mapped
to
an
efficient
binary
protocol
• End
devices
can
have
both
client
and
server
roles,
can
also
communicate
directly
• Resource
representaJon
e.g.
‘applicaJon/
json’,
is
negoJated
as
in
hp
protocol
CoAP
• Observe
opJon
for
long-‐term
event
stream
response
to
GET,
asynchronous
updates
• Web
linking
using
IETF
standard
core-‐link-‐
format
(RFC
6690)
• Resource
discovery
using
./well-‐known/core
or
external
Resource
Directory
HTTP/REST
• HTTP
and
REST
is
useful
for
most
web
applicaJons,
services,
and
gateways
• Uses
web
callbacks,
websockets,
HTTP
PUT
for
asynchronous
updates
• Links
in
JSON,
Link-‐format,
Hypercat,
linked
data
• Well
defined
CoAP-‐to-‐HTTP
proxy
paerns,
standard
middleware
Hybrid
system
• It’s
possible
to
use
REST
for
resource
discovery
and
other
stateful
interacJons,
and
messaging
e.g.
MQTT
for
asynchronous
updates
• Various
methods
to
bind
message
endpoints
to
REST
resources
• ApplicaJon
soTware
can
easily
use
both
REST
API
and
event
handler
interfaces
like
onUpdate
• IoT
Toolkit
uses
observers
to
bind
MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Connects
REST
Resource
to
MQTT
Topic
Publish
and
Subscribe
MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Publisher
Publishes
REST
Resource
updates
to
the
broker
MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Subscriber
Makes
last
published
data
available
at
the
REST
endpoint
MQTT
Observer
MQTT
Broker
REST
Endpoint
ObservableProperty
mqObserver
PUT
GET
Publish
from
data
producer
Publish
From
REST
API
Publish
to
Other
Subscribers
SUB
Publish
to
REST
API
Pub+Sub
Repeats
data
updates
in
both
direcJons
MQTT
Bridge
to
mulJple
REST
endpoints
MQTT
Broker
REST
Endpoint
ObservableProperty
mqObserver
PUT
GET
Publish
from
data
producer
Publish
to
Other
Subscribers
REST
Endpoint
ObservableProperty
mqObserver
PUT
GET