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.
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
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
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
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
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.
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
33. Thanks!
Subscribe to our blogFollow us on Twitter Check out our whitepapers
@reappt
@push_technology
@gssor
Hinweis der Redaktion
URL – easiest to change; but ideally represents the location of resource, not version
Accept header – conforms to HTTP spec, semantically valid, adds extra work to consumer
URL – easiest to change; but ideally represents the location of resource, not version
Accept header – conforms to HTTP spec, semantically valid, adds extra work to consumer
Be a node, not a hub!
URL – easiest to change; but ideally represents the location of resource, not version
Accept header – conforms to HTTP spec, semantically valid, adds extra work to consumer
URL – easiest to change; but ideally represents the location of resource, not version
Accept header – conforms to HTTP spec, semantically valid, adds extra work to consumer
What do we mean when we say that an application is responsive?
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.
Note to BF: put this quote in the same format as the Gartner quote earlier in the deck.
Jarrett’s Notes