api days paris - when restful may be considered harmful
TRANSCRIPT
When RESTful may be considered harmful
Copyright Push Technology 2015
Ross Garrett @gssor
RESTful may be harmful, eh?
@gssor
4 @gssor
Copyright Push Technology 2015
What do we mean by RESTful?
5 @gssor
Copyright Push Technology 20156 @gssor
Copyright Push Technology 20157 @gssor
When WebAPIs may be considered harmful
Copyright Push Technology 2015
Ross Garrett @gssor
Copyright Push Technology 2015
(Web) Apis can sting you
9
Copyright Push Technology 2015
What constitutes “harmful”?
• Poor end-user experience
• Insufficient scaling capacity
• Inappropriate implementation / usage
• HATEOAS?
• ???
@gssor
Copyright Push Technology 2015
Poor User Experience
• This usually means slow / unreliable apps
• Often caused by the network
11 @gssor
Copyright Push Technology 2015
#1 Data redundancy
{ uid : 1234567890, title : “Something”, db_key : “some_thing_item”, modified_date : “13-06-1991”, …}
@gssor
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
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
Copyright Push Technology 2015
#2 Data delivery
Your clients
@gssor
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
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
Copyright Push Technology 2015
#3 Coupling
18 @gssor
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
Copyright Push Technology 2015 @gssor
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
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
Copyright Push Technology 2015
Recommendations?
• STOP polling!
• Remove data redundancies
• Avoid coupling
@gssor
Copyright Push Technology 2015
Think Reactive
24
http://www.reactivemanifesto.org
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.
Copyright Push Technology 2015
A Responsive System depends on one that is Resilient & Elastic
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
27
Resilient = Reliable
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
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
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
Copyright Push Technology 2015
There is no “one size fits all” approach, think strategically and critically about your architecture
choices
31
Copyright Push Technology 2015
Questions?
32
Thanks!
Subscribe to our blogFollow us on Twitter Check out our whitepapers
@reappt
@push_technology
@gssor