My presentation from API Days Paris, December 2015. There is no single design decision that answers every question, but in the question of whether RESTful maybe considered harmful – this session will explore how some design decisions may be leading to poor user experiences and negatively affecting your business. We'll discuss the principles of reactive applications and how streaming APIs can deliver significant benefits over RESTful APIs.

2. When RESTful may be
considered harmful
Copyright Push Technology 2015
Ross Garrett @gssor

3. RESTful may be harmful, eh?
@gssor

4. 4
@gssor

5. Copyright Push Technology 2015
What do we mean by RESTful?
5
@gssor

6. Copyright Push Technology 20156
@gssor

7. Copyright Push Technology 20157
@gssor

8. When WebAPIs may be
considered harmful
Copyright Push Technology 2015
Ross Garrett @gssor

9. Copyright Push Technology 2015
(Web) Apis can sting you
9

10. Copyright Push Technology 2015
What constitutes “harmful”?
• Poor end-user experience
• Insufficient scaling capacity
• Inappropriate implementation / usage
• HATEOAS?
• ???
@gssor

11. Copyright Push Technology 2015
Poor User Experience
• This usually means slow / unreliable apps
• Often caused by the network
11
@gssor

12. Copyright Push Technology 2015
#1 Data redundancy
{
uid : 1234567890,
title : “Something”,
db_key : “some_thing_item”,
modified_date : “13-06-1991”,
…
}
@gssor

13. Copyright Push Technology 2015
#1 Data redundancy
{
uid : 1234567890,
title : “Something else”,
db_key : “some_thing_item”,
modified_date : “06-08-2015”,
…
}
It’s like the Internet is running with Debug turned on
@gssor

14. Copyright Push Technology 2015
Insufficient scaling capability
• Growing from 1000 users to 1,000,000 users
• Should we simply add CPUs, NICs, etc?
14
@gssor

15. Copyright Push Technology 2015
#2 Data delivery
Your clients
@gssor

16. Copyright Push Technology 2015
#2 Data delivery
• How many requests do you service for data that hasn’t changed?
• Guess what? HTTP 304 is a thing
• Everything has a cost; only pay for what you need
@gssor

17. Copyright Push Technology 2015
Inappropriate Implementation
• WebAPIs often mimic backend systems & operations
• If one system needs to notify another about an event - do they really
need to know about each other?
17
@gssor

18. Copyright Push Technology 2015
#3 Coupling
18
@gssor

19. Copyright Push Technology 2015
#3 Coupling
• Message-driven distributed architectures prove to be much more
robust and fault-tolerant.
• Producers and consumers are truly independent.
• Scalability is easier to achieve, and we can distribute messages to
multiple systems at a time.
@gssor

20. Copyright Push Technology 2015
@gssor

21. Copyright Push Technology 2015
The Internet…
• Unknown, uncontrolled resource
• It will let you down
– Insufficient bandwidth
– Inconsistent bandwidth
– High latency
– Loss of connectivity on a regular basis
• Be sympathetic to realities of the network
@gssor

22. Copyright Push Technology 2015
The (mobile) Internet…
• HTTP & TCP slow-start are usually not a good match for constantly
dropped connections
• Network interface kills battery
• Large responses + periodic polling = bad
@gssor

23. Copyright Push Technology 2015
Recommendations?
• STOP polling!
• Remove data redundancies
• Avoid coupling
@gssor

24. Copyright Push Technology 2015
Think Reactive
24
http://www.reactivemanifesto.org

25. Copyright Push Technology 2015
Responsiveness
• As far as users’ know - when application response time exceeds their expectations they
assume the system is down
• Slow responses tie up resources on the called system and the calling application
25
A responsive system is quick to react to all
users — under blue skies and grey skies — in
order to ensure a consistently positive user
experience.

26. Copyright Push Technology 2015
A Responsive System depends on one that
is Resilient & Elastic
26

27. Copyright Push Technology 2015
Resilient
• A Resilient system can react to variable conditions and failures
• A resilient system keeps processing transactions, even when there are transient impulses,
persistent stresses or component failures disrupting normal processing
27
Resilient = Reliable

28. Copyright Push Technology 2015
Elastic
• An elastic system can allocate / de-allocate resources for every individual component or
client as demand varies
• Elasticity also requires non-blocking design
28
Elastic is another word for Scalable

29. Copyright Push Technology 2015
Message Driven
• A message-driven application may be event-driven, actor-based, or a combination of the two
• An event-driven system is based on events which are monitored by zero or more observers
– The caller doesn’t need to block waiting for a response from the invoked routine
• Event-driven applications are not focused on the call stack, but rather on triggering events
• Events may be encoded as messages that are placed in a queue that is monitored by zero or
more observers
29

30. Copyright Push Technology 2015
The right fit
• WebAPIs have solved lots of problems, and provided lots of
opportunity
• Reactive apps almost always demand streaming pub/sub messaging
– Websockets!
• Conceptual simplicity != best performance

31. Copyright Push Technology 2015
There is no “one size fits all” approach, think
strategically and critically about your architecture
choices
31

32. Copyright Push Technology 2015
Questions?
32

33. Thanks!
Subscribe to our blogFollow us on Twitter Check out our whitepapers
@reappt
@push_technology
@gssor