Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

API Days Paris - When RESTful may be considered harmful

363 vues

Publié le

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.

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

API Days Paris - When RESTful may be considered harmful

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

×