In the near future, everything will be connected: cities, enterprises, human beings, and more. This reality is just over the horizon, and it brings one of the largest challenges in building distributed systems. Today, developers often look to RESTful Web APIs to solve these problems. Are current trends in API design really prepared to handle the demands of the future? What’s missing from the equation? Learn new patterns for modeling Web APIs using state machines, hypermedia, and reactive streams to meet tomorrow’s challenges and make a solid attempt at standing the test of time.

1. Reactive Hypermedia APIs
Kevin Swiber
CODEMASH V2.0.1.5

2. I Like Buzzwords

3. Open source platform for
the Internet of Things
http://zettajs.org

4. APIs Suck

5. /data.cgi

6. /data.cgi
N00BIE

7. .NET Remoting

8. .NET Remoting
BROKEN

9. SOAP

10. SOAP
STUPID

11. RESTful?

12. RESTful?
WRONG

13. Hypermedia!

14. Hypermedia!NERD

15. What’s the problem?

16. The real world is complex

17. Feedback can be vicious

18. We fool ourselves into thinking
all problems are the same

20. There is no silver bullet

21. Love the bomb

22. The 15th Standard

23. Back to Zetta (IoT)

24. Reaching the Edge
DevicesDevicesDevices
Zetta
Zetta
DevicesDevicesDevices
Zetta
ClientsClientsClients
ClientsClientsClients Local Network
Data Center
Internet
The only thing we control

25. Desired Architectural
Properties
• Decoupling of implementations
• Independent evolution
• Scale
• Load balancing
• Centralize complexity, distribute simplicity
• Reduce latency
• Support event streams

26. Architectural Constraints
• Client-server, stateless, cacheable, layered
system, uniform interface, etc.
Wait, isn’t that REST?

27. The hypest of all media!
http://sirenspec.org

28. What about event streams?

29. How streams are done over
HTTP today
• WebHooks
• Chunked Transfer-Encoding
• HTTP Pipelining
• Long Polling
• Server Sent Events
X
X
X
X
X

30. Just upgrade

31. Connection info is in the
action parameters or link URI
• mqtt://example.org:8863/topic
• stomp+ws://example.org/topic
• amqp://example.org/topic
• { “href”: “ws://example.org”, “protocol”: “custom” }

32. It works!

33. Model resources as finite
state machines
LED.prototype.init = function(config) {
config
.type('led')
.state('off')
.when('off', { allow: ['turn-on'] })
.when('on', { allow: ['turn-off'] })
.map('turn-on', this.turnOn)
.map('turn-off', this.turnOff);
};

34. Transitions are represented as
affordances in the message.
"actions": [
{
"name": "turn-on",
"method": "POST",
"href": “...”,
"fields": [
{
"name": "action",
"type": "hidden",
"value": "turn-on"
}
]
}
]

35. We need to consume an
object stream.
links: [
{
title: “pulse“,
rel: [“http://rxapi.org/object-stream“],
href: “ws://...”
}
]

36. We need to consume an
object stream.
» wscat -c ws://...
connected (press CTRL+C to quit)
< {"topic":"heartbeat/1/pulse","timestamp":1411757412119,"data":61}
< {"topic":"heartbeat/1/pulse","timestamp":1411757412620,"data":65}
< {"topic":"heartbeat/1/pulse","timestamp":1411757413121,"data":69}
< {"topic":"heartbeat/1/pulse","timestamp":1411757413622,"data":71}
< {"topic":"heartbeat/1/pulse","timestamp":1411757414124,"data":66}
< {"topic":"heartbeat/1/pulse","timestamp":1411757414626,"data":64}
< {"topic":"heartbeat/1/pulse","timestamp":1411757415128,"data":68}
< {"topic":"heartbeat/1/pulse","timestamp":1411757415629,"data":63}
< {"topic":"heartbeat/1/pulse","timestamp":1411757416130,"data":65}
< {"topic":"heartbeat/1/pulse","timestamp":1411757416631,"data":63}

37. Monitor resource events
before taking action.
links: [
{
title: “logs“,
rel: [
“monitor“,
“http://rxapi.org/object-stream“
],
href: “ws://...”
}
]

38. Monitor resource events
before taking action.
» wscat -c ws://...
connected (press CTRL+C to quit)
< {"topic":"led/2/logs","timestamp":
1411809676901,"transition":"turn-on","input":[],"properties":
{"id":"2","type":"led","name":null,"state":"on"}}
< {"topic":"led/2/logs","timestamp":
1411809677548,"transition":"turn-off","input":[],"properties":
{"id":"2","type":"led","name":null,"state":"off"}}
< {"topic":"led/2/logs","timestamp":
1411809678483,"transition":"turn-on","input":[],"properties":
{"id":"2","type":"led","name":null,"state":"on"}}
< {"topic":"led/2/logs","timestamp":
1411809679126,"transition":"turn-off","input":[],"properties":
{"id":"2","type":"led","name":null,"state":"off"}}

39. We also need binary.
links: [
{
rel: [“http://rxapi.org/binary-stream“],
href: “ws://...“,
type: “video/mpeg“,
}
]

40. We also need binary.
» wscat -c ws://...
connected (press CTRL+C to quit)
Q`rCEDˌDIp=`"3ss79:Yk}{` 5e`>9%J[K89z^> 8X Gp;W̮qXF
h1{%O;7<Bi‫.ڞ‬r r5
vyeK[X@ƯDRmT:uLz[‫ޱްޯޮޭެޫުީިާަޥޤޣޢޡޠޟޞޝޜޛޚޙޘޗޖޕޔޓޒޑސޏގލތދފމވއކޅބރނށހ‬V
.vK",,u!N8֝=LQ=s~ӆ`]{E6[
WȝM]3Uo|&n
Њmo('/K>2칩e,l{%`:<rtN|SXu曆psFJS*s#AB]ý0Rt_`uS}vX3ctA>kJfuΎ^L๖䜼V"u8GU
‫*ڹ‬

41. We also need binary.
» wscat -c ws://...
connected (press CTRL+C to quit)

42. Reactive Clients
var siren = require('siren');
!
siren()
.load('http://zetta-cloud-2.herokuapp.com')
.link('http://rels.zettajs.io/peer', 'Detroit')
.entity(function(e) {
return e.properties.type === 'sound';
})
.link('http://rels.zettajs.io/object-stream', 'level')
.monitor()
.subscribe(console.log);

43. Reactive Clients
var zrx = require('zrx');
!
zrx()
.load('http://zetta-cloud-2.herokuapp.com')
.server('Detroit')
.device(function(d) {
return d.type === 'sound';
})
.stream('level')
.subscribe(console.log);

44. Going Forward

45. Solve the producer-
consumer problem.

46. Reactive Stream Control
Protocol
• Consumer controlled streams
• Runs over WebSockets
• Multiplex streams
• URI scheme definition
• Will be supported on HTTP/2 + WebSockets.

47. What can you do with
streams?
• Monitoring values over time
• Distributed data processing
• Event sourcing
• Batches

48. // TODO:
• Extract reactive hypermedia framework from
Zetta internals.
• Produce a clean specification and
documentation.
• Experiment with multiple languages/platform
implementations.

49. Hit me up!
• kswiber@gmail.com
• https://twitter.com/kevinswiber
• https://linkedin.com/in/kevinswiber
• https://github.com/kevinswiber