API Days Paris - When RESTful maybe considered harmful

My presentation from API Paris, Dec 2015. Discussing the limitations and problems of Web APIs at scale, and looking at real-time streaming APIs as a better alternative in some use cases.

Transcript

1. When RESTful may be considered harmful Copyright Push Technology 2015 Ross Garrett @gssor
2. RESTful may be harmful, eh? @gssor
3. 3 @gssor
4. Copyright Push Technology 2015 What do we mean by RESTful? 4 @gssor
5. Copyright Push Technology 2015 5 @gssor
6. Copyright Push Technology 2015 6 @gssor
7. When WebAPIs may be considered harmful Copyright Push Technology 2015 Ross Garrett @gssor
8. Copyright Push Technology 2015 (Web) Apis can sting you 8
9. Copyright Push Technology 2015 What constitutes “harmful”? • Poor end-user experience • Insufficient scaling capacity • Inappropriate implementation / usage • HATEOAS? • ??? @gssor
10. Copyright Push Technology 2015 Poor User Experience • This usually means slow / unreliable apps • Often caused by the network 10 @gssor
11. Copyright Push Technology 2015 #1 Data redundancy { uid : 1234567890, title : “Something”, db_key : “some_thing_item”, modified_date : “13-06-1991”, … } @gssor
12. 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
13. Copyright Push Technology 2015 Insufficient scaling capability • Growing from 1000 users to 1,000,000 users • Should we simply add CPUs, NICs, etc? 13 @gssor
14. Copyright Push Technology 2015 #2 Data delivery Your clients @gssor
15. 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
16. 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? 16 @gssor
17. Copyright Push Technology 2015 #3 Coupling 17 @gssor
18. 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
19. Copyright Push Technology 2015 @gssor
20. 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
21. 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
22. Copyright Push Technology 2015 Recommendations? • STOP polling! • Remove data redundancies • Avoid coupling @gssor
23. Copyright Push Technology 2015 Think Reactive 23 http://www.reactivemanifesto.org
24. 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 24 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.
25. Copyright Push Technology 2015 A Responsive System depends on one that is Resilient & Elastic 25
26. 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 26 Resilient = Reliable
27. 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 27 Elastic is another word for Scalable
28. 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 28
29. 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
30. Copyright Push Technology 2015 There is no “one size fits all” approach, think strategically and critically about your architecture choices 30
31. Copyright Push Technology 2015 Questions? 31
32. Thanks! Subscribe to our blog Follow us on Twitter Check out our whitepapers @reappt @push_technology @gssor