The document discusses reactive hypermedia and a new approach for API design that uses state machines and event-driven architecture. Key points include: - Current popular APIs use a client-server model but this new approach combines event-driven design with client-server. - Resources will be modeled as finite state machines and API responses will represent these state machines. - The architecture supports consuming streaming data and event notifications through websockets. - This reactive approach allows greater control over latency and more flexible access to distributed resources and data streams.

1. Reactive Hypermedia
Kevin Swiber

2. It’s true.

3. I work on an open source platform
for the Internet of Things.
http://zettajs.org

4. The World As We
Know It

5. The most popular APIs
are URL-first.

6. Client-server architecture
is abundant.

7. Event-Driven Architecture
is often in a silo.

8. We are modeling HTTP handlers
as actions on controllers.

9. Change is Coming

10. We are shifting from full
service to self service.

11. We are moving from few
and big to many and small.

12. We are progressing from
rigid to flexible.

13. Distributed
Questions

14. How do we allow clients
to access resources
hosted on any server?

15. How can API Resources offer
event-driven data streams?

16. How can we manage state
in our API Resources?

17. How can we make resource transition
availability a responsibility of the
server?

18. How do we gain greater
control over latency?

19. Constraints

20. Resource abstractions
must be joyful to use.

21. Proxies are a common
component in the architecture.

22. Clients may need to contend with
resources that are not yet available.

23. Everything needs an API.

24. A New Approach

25. API responses must
represent state machines.

26. Event-driven design must run
alongside tried and true client-server.

27. Multiple servers will be
responsible for processing logic.

28. Utilize reactive
programming.

29. Implementation

30. 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);
};

31. Use a hypermedia type that can
represent the state machine model.

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

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

34. 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}

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

36. 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"}}

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

38. 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粦
*ڹ

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

40. Clients work!

41. Going Forward

42. Solve the producer-consumer
problem.

43. We need to do a best-effort doc
generation from state machines.

44. Build reactive clients.
get(‘http://...‘)
.links()
.where({ ‘rel‘, { contains: ‘monitor‘ })
.subscribe(function(data) {
console.log(‘Received:‘, data);
});

45. Make more.

46. Share. :)

47. Questions?
• kswiber@gmail.com
• https://twitter.com/kevinswiber
• https://linkedin.com/in/kevinswiber
• https://github.com/kevinswiber