Evolving REST for an IoT World Todd L. Montgomery @toddlmontgomery - - PowerPoint PPT Presentation

evolving rest for an iot world
SMART_READER_LITE
LIVE PREVIEW

Evolving REST for an IoT World Todd L. Montgomery @toddlmontgomery - - PowerPoint PPT Presentation

Evolving REST for an IoT World Todd L. Montgomery @toddlmontgomery Representational State Transfer http://en.wikipedia.org/wiki/Representational_state_transfer @toddlmontgomery protocol noun \ pr -t - k o l, - k l, -


slide-1
SLIDE 1

Evolving REST for an IoT World

Todd L. Montgomery @toddlmontgomery

slide-2
SLIDE 2

@toddlmontgomery

Representational State Transfer

http://en.wikipedia.org/wiki/Representational_state_transfer

slide-3
SLIDE 3

@toddlmontgomery

pro·to·col noun \ˈprō-tə-ˌkȯl, -ˌkōl, -ˌkäl, -kəl\

  • ...
  • 3 b : a set of conventions governing the treatment and especially the

formatting of data in an electronic communications system <network protocols> ... 3 a : a code prescribing strict adherence to correct etiquette and precedence (as in diplomatic exchange and in the military services) <a breach of protocol>

slide-4
SLIDE 4

@toddlmontgomery

Client - Server Cacheable Stateless

slide-5
SLIDE 5

@toddlmontgomery

Uniform Interface

Hypermedia, Resources, URIs

Layered

Hmmm…

slide-6
SLIDE 6

@toddlmontgomery

REST Ecosystem

slide-7
SLIDE 7

@toddlmontgomery

Tools - CLI Browser JSON

Fast, Easy Integration

HTTP/1.1,TCP, [TLS/SSL], IP

slide-8
SLIDE 8

@toddlmontgomery

IoT/IoE Ecosystem

slide-9
SLIDE 9

@toddlmontgomery

Boards & Kits Environments JSON ??

Evolving Rapidly

HTTP/1.1 TLS/SSL? TCP IP Bluetooth MQTT SCADA Application App? App

Multiple Stacks

slide-10
SLIDE 10

@toddlmontgomery

Communication Patterns

Request/Response Streaming “Ingest” Publish/Subscribe Request/Response

slide-11
SLIDE 11

@toddlmontgomery

History & Evolution

slide-12
SLIDE 12

@toddlmontgomery

Request Response

HTTP

RFC 2068, 2616, …, 7230-7240

Synchronous Request/Response

Bi-Directional… kinda, but…

Event Event

… only

  • ne direction

at-a-time

June 2014

slide-13
SLIDE 13

@toddlmontgomery

Request Response Delay Delay Processing

What happens here while waiting? …Nothing… Stop-and-Wait HTTP

slide-14
SLIDE 14

@toddlmontgomery

image courtesy www.tensator.com

Head-Of-Line Blocking

slide-15
SLIDE 15

@toddlmontgomery

Latency Sensitivity

slide-16
SLIDE 16

@toddlmontgomery

Mobile

“OK” Bandwidth + Long RTT + High Loss Rate + No Effective HTTP Pipelining

http://en.wikipedia.org/wiki/HTTP_pipelining

Truly Awful User Experiences

slide-17
SLIDE 17

@toddlmontgomery

Asynchronous Request / Response

Unlock More Reactive Patterns!

slide-18
SLIDE 18

@toddlmontgomery

Request ACK Response ACK

Sync Request Sync Response Web Services

But… Async Request/Response… kinda

Event Event

http://en.wikipedia.org/wiki/List_of_web_service_specifications

No, seriously, lots of these!!

slide-19
SLIDE 19

@toddlmontgomery

Thankfully, Locked within the Enterprise…

Mostly…

slide-20
SLIDE 20

@toddlmontgomery

“Yeah, yeah, but your scientists were so preoccupied with whether

  • r not they could that they didn't

stop to think if they should.” — Jurassic Park

Philosophy of some REST APIs

Just because you could use HTTP, doesn’t mean you should…

slide-21
SLIDE 21

@toddlmontgomery

HTCPCP RFC 2324, Extended by RFC 7168

http://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol

"there is a strong, dark, rich requirement for a protocol designed espressoly [sic] for the brewing of coffee"

slide-22
SLIDE 22

@toddlmontgomery

slide-23
SLIDE 23

@toddlmontgomery

418 I’m a teapot BREW WHEN

"This has a serious purpose – it identifies many of the ways in which HTTP has been extended inappropriately.” — Larry Masinter, author http://larry.masinter.net/

slide-24
SLIDE 24

@toddlmontgomery

Why is HTTP used?

Easy firewall traversal Simple, Flexible, Familiar Works with Anything Addressing Tooling

slide-25
SLIDE 25

@toddlmontgomery

Communication Patterns

Request/Response Streaming “Ingest” Publish/Subscribe Request/Response

slide-26
SLIDE 26

@toddlmontgomery

Request Response

Support (UI/Device) Security (Challenge) Keep-Alive

  • r Watchdog

User State Query

slide-27
SLIDE 27

@toddlmontgomery

Battery Life

Persistent connections help a LOT! Well designed protocols help a LOT MORE! Many simultaneous connections hurt! Using the wrong protocol with the wrong pattern hurts A LOT!

The Wrong Patterns Hurt a LOT!

Stay out of High Energy State!

slide-28
SLIDE 28

@toddlmontgomery

New Protocols & Standards

slide-29
SLIDE 29

@toddlmontgomery

Async Request/ Response Streaming WebSocket

RFC 6455

Full Duplex, Asynchronous “TCP over the Web”

Events Events 1 1 S w i t c h HTTP Upgrade

Ingest

https://tools.ietf.org/html/rfc6455

Really a Transport Protocol

slide-30
SLIDE 30

@toddlmontgomery

Async Request Async Response SPDY & HTTP/2

IETF Drafts

Async Request/Response

Multiple Streams Efficient Headers (HPACK) Binary Encoding

Events Events

http://www.ietf.org/id/draft-ietf-httpbis-http2-12.txt

slide-31
SLIDE 31

@toddlmontgomery

Async Request Async Response WebSocket over HTTP/2

IETF Draft

Streaming Ingest Full Duplex, Asynchronous with Multiple Channels/Streams

Events Events

http://www.ietf.org/id/draft-hirano-httpbis-websocket-over-http2-00.txt

slide-32
SLIDE 32

@toddlmontgomery

MQ Telemetry Transport (MQTT)

http://mqtt.org/

Lightweight Publish/Subscribe Messaging Transport Runs over TCP

  • r WebSocket (v3.1.1)

MQTT-SN for non-TCP /IP Broker-Based

OASIS Standard

slide-33
SLIDE 33

@toddlmontgomery

Constrained Application Protocol (CoAP)

http://www.ietf.org/id/draft-ietf-core-coap-18.txt

Runs over UDP , DTLS,

  • r WebSocket

Request/Response (either direction), Publish/Subscribe Standardized HTTP Mapping Resource Discovery, Linking, etc.

IETF CoRE WG (Constrained RESTful Environments)

slide-34
SLIDE 34

@toddlmontgomery

Sustain REST Principles Standards-Based Easily Parsed Efficient Handling of Data/Metadata Flexible - Easily Extended Easy to Implement

Requirements

slide-35
SLIDE 35

@toddlmontgomery

Possible Game Plan(s)

WebSocket + MQTT HTTP/2 WebSocket + CoAP WebSocket + HPACK

Combining IoT & REST

slide-36
SLIDE 36

@toddlmontgomery

HTTP/2

Nothing Optional, TLS, HPACK, etc. Familiar Primitives More complex than HTTP /1.1 Ecosystems: REST Yes, IoT No

slide-37
SLIDE 37

@toddlmontgomery

WebSocket + MQTT

HTTP Mapping? WebSocket can adapt Some Guaranteed Messaging Semantics Ecosystems: IoT Yes, REST No (w/o WS) Enables Many Patterns

slide-38
SLIDE 38

@toddlmontgomery

WebSocket + HPACK

http://www.ietf.org/id/draft-ietf-httpbis-header-compression-07.txt

HPACK handles method + headers Use header for Stream ID Not a Standard, but made of Standards HPACK is (subjectively) complex

slide-39
SLIDE 39

@toddlmontgomery

WebSocket + CoAP

http://www.ietf.org/id/draft-savolainen-core-coap-websockets-02.txt

HTTP Mapping Ecosystems: REST Yes, IoT Yes No Guaranteed Messaging Not Broker-based, Peer-to-Peer

slide-40
SLIDE 40

@toddlmontgomery

One More Thing…

  • JSON
slide-41
SLIDE 41

@toddlmontgomery

Binary Encoding

Thing 1 Thing 2

Not a human Also, …not a human Does not need to be human readable

http://tools.ietf.org/html/rfc7049

Concise Binary Object Representation (COBR) FIX / Simple Binary Encoding (SBE)

https://github.com/real-logic/simple-binary-encoding

HPACK (Part of HTTP /2)

slide-42
SLIDE 42

@toddlmontgomery

Questions?

  • Kaazing http://www.kaazing.com
  • Slideshare http://www.slideshare.com/toddleemontgomery
  • Twitter @toddlmontgomery

Thank You!