(4) API Cargo Cult

(5) Looking for a good API Strategy? Look at the Web!

• Problem focus over solution focus
  • Problems are addressed by building capabilities with standardized interfaces
  • Solutions are created/managed by those who solve the problems
• Platform diversity over landscape homogeneity
  • Solution providers pick platforms based on their preferences
  • Platforms evolve and so does the platform landscape as a whole
• Solutions and platforms are completely decoupled
  • Solutions are looking at what service to provide
  • Platforms are concerned with how to implement the solution

(6) Platforms are Monoliths by Design

• Designed to provide shared tooling
• Tooling becomes the backdoor for coupling creep
• Resist the urge to provide an API platform
• Ignoring one of the two major API value propositions
  • APIs are valuable because they decouple service users and providers
  • APIs are valuable because they decouple service implementations

(7) Landscapes are Decentralized by Design

• Designed to use shared languages
• Communications/coupling can only happen through APIs
• Anything that needs to be shared must be openly communicated
• Satisfying the two major API value propositions
  • APIs are valuable because they decouple service users and providers
  • APIs are valuable because they decouple service implementations

(8) Communicating Code Couples

• Importing code means coupling with the code
• Code that does not communicate creates no external coupling
• Code that does communicate creates external coupling
  • Code that communicates via a visible API creates acceptable coupling
  • Code that communicates via hidden channels creates unacceptable coupling

(9) The Rules of MSA Club

1. The first rule of MSA club is that you can only communicate via APIs
2. The second rule of MSA club is that you can only communicate via APIs
3. The third rule of MSA club: if you communicate via side channels, you are out
4. The fourth rule of MSA club is that if you need communications, design a language

(10) Languages Encapsulate/Enable Capabilities

(11) Loose Coupling via Languages

• Apply well-known Patterns for Robust Extensibility [http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html]
  • Meaningful core semantics: Create a useful minimal language
  • Well-defined extension points: Allow the language to evolve
  • Well-defined processing model: Say how to behave when encountering extensions
• Loose coupling encourages service changes and replacements
  • Design for service changes: Non-breaking changes as the primary goal
  • Design for service replacements: Languages remain intact across implementations

(13) API Platform Monolith

(14) APIs and Microservices

(15) API Gateway

(16) API Microgateway

(17) Platform Capability Sedimentation

(19) Thanks! Q&A

• Slides online: dret.net/lectures/amfam-2017 [http://dret.net/lectures/amfam-2017]
• Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/amfam-2017] on GitHub [http://github.com/]
• Me: http://dret.net/netdret/ [http://dret.net/netdret/]
• Twitter: @dret [http://twitter.com/dret]