Autonomous APIs

Slides used during my talk at API Conference Berlin 2018 https://apiconference.net/api-business-strategy/autonomous-apis/

Abstract:

The exponential growth of APIs, further accelerated by IoT, micro-services, and FaaS, brought many challenges both technical and economical. On the one hand, businesses are struggling with establishing successful API programs to connect with their customers. On the other side, engineering teams are facing out-of-the-scale complexity.

In this talk, we will explore the problems and shortcomings of current APIs, both with regards to the technical aspects and the API economy. We will discuss the possible solutions to these problems, and introduce Autonomous APIs.
In the second part, we will take a look at what Autonomous APIs are and how they can solve the problems for both businesses and engineering. We will introduce the classification of autonomous systems and take a peek at the building blocks of autonomous systems.

Transcript

1. goodapi.co
   AUTONOMOUS APIS
   Zdenek “Z” Nemec
   goodapi.co
   

   View Slide

2. goodapi.co
   I help businesses build APIs
   Zdenek “Z” Nemec
   @zdne
   zdne1
   

   View Slide

3. goodapi.co
   APIS: THE FIRST 30 YEARS
   CUSTOMER-SPECIFIC
   APIS
   one-to-one
   First Wave (2000)
   GENERIC
   APIS
   one-to-many
   Second Wave (2010)
   HARMONIZED
   APIS
   many-to-one, machine-to-machine
   Third Wave (2020)
   The Pattern
   1990 2000 2010 2020
   

   View Slide

4. goodapi.co
   THE WAVES OF API
   TRANSFORMATION
   

   View Slide

5. goodapi.co
   goodapi.co
   CUSTOMER-SPECIFIC
   APIS
   First Wave
   

   View Slide

6. goodapi.co
   FIRST WAVE: ONE–TO–ONE
   Large organizations embracing IT (years 1990-2000s)
   

   View Slide

7. goodapi.co
   Primary Drivers
   Secondary Drivers
   Non-driver
   FIRST WAVE: ONE TO ONE
   ONE API consumed by ONE client
   

   View Slide

8. goodapi.co
   goodapi.co
   EVERY WAVE HAS
   ITS API ARCHITECTURE
   

   View Slide

9. goodapi.co
   SOAP, EDI, FTP & ESB
   CUSTOMER-SPECIFIC APIS
   FIRST WAVE ARCHITECTURE
   

   View Slide

10. goodapi.co
    FIRST WAVE COMPLEXITY
    FIRST-WAVE PROVIDERS FACING COMPLEXITY ISSUES
    FROM INCREASING NUMBER OF POINT TO POINT
    INTEGRATIONS AND/OR THE ESB SINGLE POINT OF
    FAILURE AND INCREASING DEPENDENCIES
    

    View Slide

11. goodapi.co
    NEW CONSUMERS FOUND THE FIRST-WAVE
    APIS TOO COMPLEX AND CUMBERSOME TO
    USE
    

    View Slide

12. goodapi.co
    THESE CUSTOMERS WERE OFTEN IGNORED,
    MISUNDERSTOOD AND UNDERSERVED
    BY INCUMBENTS
    

    View Slide

13. goodapi.co
    goodapi.co
    GENERIC APIS
    Second Wave
    

    View Slide

14. goodapi.co
    SECOND WAVE: ONE–TO–MANY
    Ubiquitous internet and software development (years 2005-2018+)
    

    View Slide

15. goodapi.co
    FIRST TO SECOND
    Two Groups of Customers–API Consumers
    CUSTOMER-
    SPECIFIC
    APIS
    GENERIC
    APIS
    one-to-many: many mid- or
    small- size customers
    one-to-one: few large
    established customers
    First Wave (2000) Second Wave (2010)
    

    View Slide

16. goodapi.co
    Primary Drivers
    Secondary Drivers
    Non-drivers
    SECOND WAVE: ONE TO MANY
    ONE API consumed by MANY clients
    

    View Slide

17. goodapi.co
    Fueled by the success, scalability and
    performance of the most successful API to
    date – Web
    SO-CALLED-REST & GRAPHQL
    SECOND WAVE (GENERIC APIS)
    SECOND WAVE ARCHITECTURE
    

    View Slide

18. goodapi.co
    THE (FORTUNE 500) WORLD STILL RUNS
    ON SOAP, EDI OR FTP, NOT REST
    …but the the third wave is already coming…
    However…
    

    View Slide

19. goodapi.co
    SECOND WAVE COMPLEXITY
    SECOND-WAVE PROVIDERS ARE FACING COMPLEXITY
    ISSUES FROM INCREASING NUMBER OF CLIENT
    INTEGRATIONS, NUMBER OF HOST AND CLIENT
    DEPLOYMENTS AND NUMBER OF API VERSIONS
    

    View Slide

20. goodapi.co
    NEW CONSUMERS FIND COMPLEX AND COSTLY
    TO INTEGRATE AND MAINTAIN THE
    INTEGRATIONS WITH MANY SECOND-WAVE APIS
    

    View Slide

21. goodapi.co
    THESE CUSTOMERS WERE OFTEN IGNORED,
    MISUNDERSTOOD AND UNDERSERVED
    BY INCUMBENTS
    

    View Slide

22. goodapi.co
    goodapi.co
    HARMONIZED APIS
    Third Wave
    

    View Slide

23. goodapi.co
    THIRD WAVE: MANY–TO–MANY
    Need for consuming many APIs, forming API Landscapes, Rise of IoT &
    AI (Year 2018+)
    

    View Slide

24. goodapi.co
    THERE IS TOO MANY APIS TO
    INTEGRATE WITH JUST ONE!
    B C D . . .
    e-shop
    IF I AM BUILDING AN E-SHOP DO I WANT TO
    INTEGRATE WITH 400 LOGISTICS PROVIDERS?
    THE NUMBER OF APIS IS GROWING STRONG
    

    View Slide

25. goodapi.co
    

    View Slide

26. goodapi.co
    

    View Slide

27. goodapi.co
    –Radek Novotny; CEO & founder MyStay
    “There are few integrators for
    hospitality APIs consolidating as many
    as 40 PMS but they are either not-
    duplex or slow in reactions”
    CHALLENGE: INTEGRATION
    WITH MANY PROPERTY
    MANAGEMENT SYSTEMS (PMS)
    

    View Slide

28. goodapi.co
    BUT 40+ PMS INTEGRATIONS ARE JUST ONE PART OF
    MYSTAY PROBLEMS. THE BIGGER ONE IS: HOW TO INTEGRATE
    WITH THOUSANDS OF “SMART HOSPITALITY” IOT DEVICES
    FROM DIFFERENT VENDORS AND IN DIFFERENT HOTEL CHAINS?
    

    View Slide

29. goodapi.co
    goodapi.co
    MULTIPLE
    DOMAINS
    The situation will
    get even worse
    with...
    

    View Slide

30. goodapi.co
    MANY APIS, CROSS-DOMAIN APIS
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    API
    Consumer
    APIs
    Accommoda
    tion B
    Accommoda
    tion E
    

    View Slide

31. goodapi.co
    CROSS-DOMAIN
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    Customer
    3rd party
    

    View Slide

32. goodapi.co
    UNIVERSE OF CAPABILITIES
    This is what Amazon (Alexa skills), Google
    (Home skills) & VIV are doing…
    Database of knowledge and services with uniform
    interface
    

    View Slide

33. goodapi.co
    

    View Slide

34. goodapi.co
    THIRD WAVE
    Primary Drivers
    Secondary Drivers
    Non-drivers
    1. Consuming more than one API
    2. Cross-domain
    3. Demanding reduction of
    complexity
    4. Self-driving
    5. Autonomous-decoupled from
    particular provider
    NEXT-GEN CUSTOMERS
    Partnership through
    discoverability
    Innovation driven by AI & IoT
    

    View Slide

35. goodapi.co
    UNIFORM INTERFACE, DECOUPLING,
    KNOWLEDGE SHARED AT RUNTIME,
    DECLARATIVE PROGRAMMING,
    AUTOMATION, AUTONOMY
    THIRD WAVE (AUTONOMOUS APIS)
    THIRD WAVE ARCHITECTURE
    

    View Slide

36. goodapi.co
    THE THIRD WAVE COMING…
    CUSTOMER-SPECIFIC
    APIS
    one-to-one: few large established
    customers
    First Wave (2000)
    GENERIC
    APIS
    one-to-many: many mid- or small- size
    customers
    Second Wave (2010)
    AUTONOMOUS
    APIS
    many-to-one &
    machine-to-machine:
    automatic, later
    autonomous APIs
    Third Wave (2020)
    

    View Slide

37. goodapi.co
    goodapi.co
    HOW ARE FIRST- AND SECOND-
    WAVE INCUMBENTS LOOSING THEIR
    CUSTOMERS
    

    View Slide

38. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    FIRST WAVE
    First wave of API
    customers
    Point-to-point
    integrations
    one-to-one: few
    large established
    customers
    

    View Slide

39. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    New Type of
    Customer
    Complex, legacy, point-to-
    point API interfaces
    difficult to use for new
    customers
    one(API)-to-
    many(consumers):
    many mid- or
    small- size
    customers
    SECOND WAVE Second
    wave of
    API
    customers
    

    View Slide

40. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    Facilitator
    New Type of
    Customer
    Ignored at the start
    Second
    wave of
    API
    customers
    Facilitator - Disruptor
    A 3rd party between API
    customer and API provider.
    Unrecognized or ignored it is
    either an external provider
    or shadow IT.
    SECOND WAVE
    

    View Slide

41. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    Second wave of API
    consumers
    SECOND WAVE
    

    View Slide

42. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    FIRST WAVE CUSTOMERS
    MOVING TO 3RD PARTY
    

    View Slide

43. goodapi.co
    UNABLE TO ADAPT TO THE
    INCUMBENTS ARE LOOSING THEIR POSITIONS
    TO DISRUPTORS
    

    View Slide

44. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    2ND WAVE (GENERIC APIS)
    First wave customers moving to 3rd Party
    one-to-many: many
    mid- or small- size
    customers
    

    View Slide

45. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    3RD WAVE (HARMONIZED APIS)
    3rd party providing integrations with many providers
    Incumbent Incumbent Incumbent Incumbent
    many-to-one &
    machine-to-machine:
    automatic, later
    autonomous APIs
    

    View Slide

46. goodapi.co
    THE FEAR OF BECOMING COMMODITY, LACK OF
    KNOWLEDGE LACK OF UNDERSTANDING AND INABILITY
    TO INNOVATE LEADS TO ISOLATION AND LEAVES
    INCUMBENTS ONCE AGAIN VULNERABLE TO THIRD
    PARTIES
    

    View Slide

47. goodapi.co
    IOT
    

    View Slide

48. goodapi.co
    Client Client Client Client Client Client
    HOSPITALITY
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    

    View Slide

49. goodapi.co
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    BANKING APIS
    Accelerated by PSD2
    

    View Slide

50. goodapi.co
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    LOGISTICS
    Metapack integrates
    over 400 carriers
    Over 100 (!!!) 3rd Party vendors
    

    View Slide

51. goodapi.co
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    Provider Provider Provider
    UNIFORM INTERFACE
    Uniform Interface
    to incumbents
    B C D
    e-shop
    3rd party
    

    View Slide

52. goodapi.co
    THERE IS TOO MANY APIS TO
    INTEGRATE WITH JUST ONE!
    B C D
    e-shop
    B C D
    e-shop
    3rd party
    VS.
    IF I AM BUILDING AN E-SHOP DO I WANT TO
    INTEGRATE WITH 400 LOGISTICS PROVIDERS?
    THE NUMBER OF APIS IS GROWING STRONG
    

    View Slide

53. goodapi.co
    Website A
    Client Client Client Client Client Client
    ARE YOUR CUSTOMERS
    REALLY YOURS?
    Website B Website C Website D Website E
    

    View Slide

54. goodapi.co
    COMPLEXITY
    

    View Slide

55. goodapi.co
    COMPLEXITY OF DISTRIBUTED
    COMPUTING SYSTEMS
    Task-structure Complexity
    How difficult it is
    understand how to perform
    a task in a distributed
    system
    Unpredictability
    How difficult is to predict
    effect of an action in
    distributed system, amount
    of entropy
    Size Complexity
    Size of the system implies
    cognitive complexity, large
    number of concepts and
    the knowledge required
    Chaotic Complexity
    Small variations in a certain
    part of the system can have
    large effects on overall
    system behavior
    Algorithmic Complexity
    Both traditional algorithm
    complexity in the term of
    time and space and
    cognitive complexity of
    understanding algorithm
    

    View Slide

56. goodapi.co
    COMPLEXITY EXERCISE
    5. # of client deployments
    Different lifecycle of the
    deployment
    • Desktop app
    • Web app
    • Mobile app
    • Backend
    • Scripts / CLI
    3. # of API implementations / deployments
    • Language
    • Provider
    • Protocol
    • API architectural style
    1. # of API (designs) for a domain
    2. # of versions of one API
    stripe.com API has over 70 versions
    4. # of client integrations
    Single consumer / API key
    

    View Slide

57. goodapi.co
    API Designs x Versions x Deployment Hosts x Clients x Client Deployments
    IF THE NUMBER OF
    IS HIGHER THAN TWO
    You are likely to face complexity using, maintaining and evolving your API
    130 APIs
    3 x 6 (environments x
    availability zones)
    70 versions 1500 integrations
    own deployments: 3 x 6
    on-premise deployments: 1000
    apps: 3 000 000
    IoT: ?????
    = 1,10565×10^9
    

    View Slide

58. goodapi.co
    COST OF CHANGE
    6,1% chance of breaking change every day (java library)
    

    View Slide

59. goodapi.co
    SOLUTIONS
    

    View Slide

60. goodapi.co
    1. Hire more people
    2. Standardization
    3. Apply massive automation
    4. Start building distributed systems differently–
    change the approach–autonomy of the
    components in API landscape
    SOLUTIONS TO COMPLEXITY
    

    View Slide

61. goodapi.co
    ROLE OF HUMANS IN APIS
    1. Hire More People
    Mechanical turks, eyeballing documentation for changes in
    design, fixing clients and implementations accordingly.
    

    View Slide

62. goodapi.co
    WHAT WE THINK AN API IS
    MACHINE EXPOSES
    INTERFACE
    ANOTHER MACHINE
    LEARNS & USES
    INTERFACE
    MACHINES MEET
    OVER THE NETWORK
    discovery
    

    View Slide

63. goodapi.co
    REALITY
    MACHINE EXPOSES
    INTERFACE
    ANOTHER HUMAN
    READS
    DOCUMENTATION
    HUMAN WRITES
    DOCUMENTATION
    ANOTHER MACHINE IS
    TAUGHT TO USE
    INTERFACE
    HUMANS MEET
    discovery
    !
    
    !
    
    
    

    View Slide

64. goodapi.co
    REALITY
    
    
    
    
    
    !
    HUMANS INSIDE
    VS.
    • time and money spent
    • not scaling
    • chance of
    misinterpretation
    • error-prone
    

    View Slide

65. goodapi.co
    API DESIGN, LIFECYCLE, DEVELOPMENT
    STANDARDIZATION
    2. Standardization
    

    View Slide

66. API IS BY-
    PRODUCT
    API
    DOCUMENTATION
    GENERATED FROM
    CODE
    API FIRST
    API TREATED AS
    PRODUCT
    API CONSISTENCY
    API MATURITY
    

    View Slide

67. goodapi.co
    DESIGN-
    CONSISTENCY
    API guidelines & style check automation
    

    View Slide

68. goodapi.co
    AUTOMATED, CONTRACT-DRIVEN API LIFECYCLE
    3. Massive Automation
    

    View Slide

69. goodapi.co
    KEEPING THINGS IN SYNC IS
    HARD
    
    
    
    INTERFACE
    ACTUALLY
    EXPOSED
    INTERFACE
    DOCUMENTED
    INTERFACED
    USED
    are they the same?
    are they the same?
    are they the same?
    

    View Slide

70. goodapi.co
    https://goodapi.co/api-lifecycle
    

    View Slide

71. goodapi.co
    TOOLS ARE OUR
    LIMITS
    

    View Slide

72. goodapi.co
    TOOLS ARE OUR LIMITS
    • Existing investments (tools, infrastructure & processes)
    • Bloated API Management Tools
    • Missing automation
    • Lifecycle orchestration
    • Limiting API description formats
    • Data modeling from the past
    • Missing tooling for structured data
    

    View Slide

73. goodapi.co
    Components autonomy in an API Landscape reduces the
    complexity, enables scaling, and promotes the service
    commoditization.
    Autonomy is the solution to the difficulty of managing many
    components centrally.
    4. Change the approach
    AUTONOMOUS APIS
    “Autonomy: freedom from external control or influence;
    independence; sovereignty in making decisions and
    changes.”
    –New Oxford American Dictionary
    

    View Slide

74. goodapi.co
    API
    LANDSCAPES
    APIs are no longer in silos
    

    View Slide

75. goodapi.co
    MANY APIS, CROSS-DOMAIN APIS
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    API
    Consumer
    APIs
    Accommoda
    tion B
    Accommoda
    tion E
    

    View Slide

76. goodapi.co
    THE GOAL IS TO NAVIGATE
    SAFELY IN API LANDSCAPE
    Navigation through autonomic units
    Countries, Regions, Cities, City
    Quarters are autonomous regions
    but when you are driving from A to B
    you need to navigate through their
    roads
    A
    B
    Design-time & Runtime Navigation
    You need both to follow a map and
    traffic signs to navigate effectively
    

    View Slide

77. goodapi.co
    5 LEVELS OF
    AUTONOMY
    

    View Slide

78. goodapi.co
    –Autonomous Client
    “The level of autonomy is the ability to safely navigate
    in the API landscape (where the only constraints are
    time and price)”
    

    View Slide

79. goodapi.co
    LEVEL 0
    • Tightly coupled components
    • No semantics, interface or lifecycle
    data
    • Pros
    • Time to delivery for point to point
    integrations when complexity is
    low
    • Cons
    • Everything breaks when
    something changes
    • Not scaling with growing
    complexity
    Brittle System
    

    View Slide

80. goodapi.co
    LEVEL 1
    • Tightly coupled components
    • Interface metadata available
    • Human only-semantics metadata
    available
    • No lifecycle metadata (is the
    documentation documenting the
    interface implementation?)
    • Pros
    • Possible API productization
    • Reusability
    • Cons
    • Lock on changes, unable to evolve
    Documented
    Brittle System
    

    View Slide

81. goodapi.co
    LEVEL 2
    • Mostly tightly coupled components
    • Metadata are verified, valid and
    reliable
    • Metadata are human or machine
    readable
    • Advertisement of the interface,
    semantics and lifecycle metadata
    • Client subscription to future changes
    • Pros
    • Explicit understanding of price and
    risk of making changes in the API
    landscape
    • Quality Control
    • Cons
    • Advanced mindset change
    involving many people
    • Cultural denial, hard to get buy-in
    Automated
    System
    

    View Slide

82. goodapi.co
    LEVEL 3
    • Decoupled components
    • Evolvability of the components in their
    respective environments
    • Share understanding-metadata at
    RUNTIME
    • Pros
    • Reducing price and risk of making
    changes (by design)
    • Cons
    • Difficult taking everything into
    account, prone to chaotic & size
    complexity
    Decoupled
    Automated System
    

    View Slide

83. goodapi.co
    LEVEL 4
    • Self driving clients
    • Autonomy of the components
    • Leveraging learned data from
    simulation for infrastructure
    • Pros
    • Higher level of abstraction
    • Uniform interface
    • Cons
    • Cognitive (Algorithmic) Complexity
    • Demanding on computational
    power
    • Higher level of abstraction
    Autonomous
    System
    

    View Slide

84. goodapi.co
    LEVELS OF AUTONOMY
    Brittle System
    Documented Brittle System
    Automated System
    Decoupled Automated System
    Autonomous System
    Autonomy
    Autonomous APIs
    0
    1
    2
    3
    4
    

    View Slide

85. goodapi.co
    BUILDING BLOCKS OF
    AUTONOMOUS APIS
    

    View Slide

86. goodapi.co
    BUILDING BLOCKS OF
    AUTONOMOUS APIS
    • Uniform Interface
    • Decoupled components
    • API understanding shared at run-time
    Level 4
    Autonomous System
    Level 3
    Decoupled Automated System
    • Client components programmed declaratively -
    self driving clients
    • Machine understanding
    • API Landscape understanding shared at run-time
    4
    3
    

    View Slide

87. goodapi.co
    goodapi.co
    Early four-engine jets required flight engineers.
    Later four-engine jets were designed with
    sufficient automation to eliminate the position.
    747 FLIGHT ENGINEERS
    ...this will also happen in the world of APIs.
    

    View Slide

88. goodapi.co
    Level 3
    Decoupled Automated System
    3
    

    View Slide

89. goodapi.co
    UNIFORM
    INTERFACE
    decoupled automated system building block 1/3
    

    View Slide

90. goodapi.co
    ENGINEERING PRINCIPLE OF
    GENERALITY
    1957 2018
    

    View Slide

91. goodapi.co
    A CONSISTENT, PREDICTABLE WAY
    TO QUERY DATA AND EXERCISE
    ACTIONS REGARDLESS OF THE
    SERVICE PROVIDER
    

    View Slide

92. goodapi.co
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    Provider Provider Provider
    UNIFORM INTERFACE
    Uniform Interface
    to incumbents
    B C D
    e-shop
    3rd party
    

    View Slide

93. goodapi.co
    UNIFORM INTERFACE
    HAS MANY BENEFITS
    • Simplifies architecture
    • Improves visibility of interactions
    • Decouple components, enables evolution
    • Improves interoperability, reduces cost of integration
    • Reduces costs and time to market
    • Enables autonomous service discovery
    • ENABLES FOR GENERAL AI
    • Automatic clients
    • Autonomous clients
    

    View Slide

94. goodapi.co
    CROSS-DOMAIN
    UNIFORM INTERFACE
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    Customer Customer Customer
    3rd party
    Customer Customer Customer
    Uniform Interface
    

    View Slide

95. goodapi.co
    PATH TO UNIFORM
    INTERFACE
    1. Apply Modern Architectural Styles (REST) and Linked
    Data (JSON-LD)

    

    2. Leave it up to 3rd Party Vendors (Amazon, Google..)
    to become the intermediaries to the universe
    

    View Slide

96. goodapi.co
    Do you want to provide an uniform interface or
    leave it to third-party vendor to do it?
    BUILDING YOUR NEXT
    API
    Client Client Client Client Client Client
    Provider Provider Provider
    Client Client Client
    Linked Data & Architecural Style
    Client Client Client
    Provider Provider Provider
    - OR -
    

    View Slide

97. goodapi.co
    DECOUPLED
    COMPONENTS
    decoupled automated system building block 2/3
    

    View Slide

98. goodapi.co
    A COMPONENT DOES NOT DUPLICATE OR RELY
    ON ANY OTHER COMPONENT INTERNAL LOGIC
    NEITHER IT RELIES ON ANY OTHER
    COMPONENT INFORMATION SHARED AHEAD OF
    TIME
    

    View Slide

99. goodapi.co
    API TASKS IS TO ABSTRACT
    AWAY THE INTERNALS OF
    SERVICE COMPONENT
    

    View Slide

100. goodapi.co
     DECOUPLED
     COMPONENTS
     Enable parts to evolve independently
     Abstraction
     Layer
     Comp-A Comp-B
     no welding of
     components
     

     View Slide

101. goodapi.co
     DEGRADED
     EFFICIENCY
     UI
     Transformation
     Comp-A Comp-B
     Transformation
     The Tradeoff of Decoupled components and Uniform interface
     

     View Slide

102. goodapi.co
     API UNDERSTANDING
     SHARED AT RUN-TIME
     decoupled automated system building block 3/3
     

     View Slide

103. goodapi.co
     API UNDERSTANDING
     SHARED AT RUN-TIME
     • Available HATEOAS state transitions
     • HAL, Siren, RESTful JSON
     • Non-authoritative parameter validations
     • JSON Schema, CoD
     • API Description - map
     • OpenAPI Specification, API Blueprint …
     • GraphQL Schema
     

     View Slide

104. goodapi.co
     BUILDING BLOCKS OF
     AUTONOMOUS APIS
     • Uniform Interface
     • Decoupled components
     • API understanding shared at run-time
     Level 3
     Decoupled Automated System
     3
     

     View Slide

105. goodapi.co
     Level 4
     Autonomous System
     4
     

     View Slide

106. goodapi.co
     DECLARATIVE CLIENT
     PROGRAMMING
     autonomous system building block 1/3
     

     View Slide

107. goodapi.co
     DECLARATIVE
     PROGRAMMING
     // HTTP Request
     GET /v1/balance HTTP/1.1
     Host: api.stripe.com
     Authorization: Basic c2tfdGVzdF9CUW9raWtKT3ZCaUkySGxXZ0g0b2xmUTI
     // Imperative, hard-coded
     fetch(‘http://api.stripe.com/v1/balance‘,
     {
     ‘Authorization': 'Basic ' + base64.encode(username + ":" + password)
     }
     ).then..
     // Declarative, decoupled
     if (hasAffordance(‘retrieve-balance’) {
     exerciseAffordance(‘retrieve-balance’).then..
     }
     

     View Slide

108. goodapi.co
     MACHINE
     UNDERSTANDING
     autonomous system building block 2/3
     

     View Slide

109. goodapi.co
     API SEMANTIC LAYERS
     Protocol
     Message
     Application
     HTTP Protocol Semantics
     HAL Semantics
     Application Domain Semantics
     (e.g. Hospitality domain)
     

     View Slide

110. goodapi.co
     DATA MODELS
     &
     VOCABULARIES,
     ONTOLOGIES
     

     View Slide

111. goodapi.co
     CANONICAL DATA
     MODEL DOESN’T
     WORK
     goodapi.co
     

     View Slide

112. goodapi.co
     CANONICAL DATA MODEL IS
     ANTI-PATTERN IN THE WORLD
     OF
     MICROSERVICES & FAAS
     Use concern separation, bounded context,
     DDD techniques
     

     View Slide

113. goodapi.co
     DOMAIN-DRIVEN DESIGN
     Divide and conquer complexity by bounded context and context mapping
     images from
     Domain-Driven-Distilled
     

     View Slide

114. goodapi.co
     CONTEXT MAPPING
     images from
     Domain-Driven-Distilled
     

     View Slide

115. goodapi.co
     LINKED DATA -
     SEMANTICS FOR
     HUMANS & MACHINES
     

     View Slide

116. goodapi.co
     –Autonomous Client
     “I am looking for a person, but I see an user, should I
     treat it as person?”
     

     View Slide

117. goodapi.co
     SHARED VOCABULARIES
     

     View Slide

118. goodapi.co
     https://supermodel.io
     

     View Slide

119. goodapi.co
     PROGRAM FOR VOCABULARY
     NOT
     DATA STRUCTURE
     

     View Slide

120. goodapi.co
     CLIENT EXAMPLE
     // Programming for data structure
     if (todo.title) {
     display todo.title
     }
     // Programming for vocabulary
     if (todo.has(‘schemaorg:title’)) {
     display todo(‘schemaorg:title’)
     }
     

     View Slide

121. goodapi.co
     DISCOVERABLE BY
     MACHINES
     autonomous system building block 3/3
     

     View Slide

122. goodapi.co
     • Rapid API
     • Any API
     • APIS.json
     • Hitch HQ (acquired)
     • GraphQL Hub
     • …
     YAHOOS OF API WORLD
     • Internal Developer
     Portals
     • API Repositories
     (Apiary, SwaggerHub)
     Human-only, hand picked
     GLOBAL COMPANY-WIDE
     

     View Slide

123. goodapi.co
     • Netflix Zulu / Eureka
     • Apache / Kafka / Zookeper
     • Hashicorp / Consul
     • Linkerd
     MICROSERVICE
     DISCOVERY
     NO SEMANTICS METADATA DISCOVERY SERVICES
     

     View Slide

124. goodapi.co
     BUT THESE ARE NOT ENOUGH
     WE NEED PUBLISH-SUBSCRIBE MODEL FOR
     MACHINE-READABLE SEMANTICS, INTERFACE
     AND LIFECYCLE METADATA
     

     View Slide

125. goodapi.co
     AUTONOMOUS SERVICE
     DISCOVERY
     “Get me a service that knows weather in Paris.”
     “Get me a service that can fulfill the parcel logistics of 6 pallets from Prague
     to Paris.”
     “Get me a service that can play every movies by the director of movie Avatar.”
     

     View Slide

126. goodapi.co
     SERVICE DISCOVERY & DECLARATIVE
     CLIENT PROGRAMMING
     // Using a terms from schema.org dictionary,
     // find services that offers WeatherForecast.
     services = apiLandscape.find(WeatherForecast, { vocabulary: http://
     schema.org})
     // Query a service for WeatherForecast at GeoCoordinates.
     forecast = service.retrieve(WeatherForecast, { GeoCoordinates: … })
     // Display Temperature
     display forecast(Temperature)
     

     View Slide

127. goodapi.co
     WHOLESALE PRESENCE
     & COMMODITIZATION
     Look for a service that has
     gs1:Offer
     where
     gs1:itemOffered gs1:gpcCategoryCode
     is
     MILK
     

     View Slide

128. goodapi.co
     apiLandscape.do(“Refill paper A4 100pcs in the
     printer on the 2nd floor”, “$10”, “24h”)
     => false
     => Promise
     NLP, DISCOVERY AND
     DECLARATIVE PROGRAMMING
     

     View Slide

129. goodapi.co
     BUILDING BLOCKS OF
     AUTONOMOUS APIS
     Level 4
     Autonomous System
     4
     • Client components programmed declaratively -
     self driving clients
     • Machine understanding
     • API Landscape understanding shared at run-time
     

     View Slide

130. goodapi.co
     ATTACKING THE
     COMPLEXITY WITH
     AUTONOMY
     

     View Slide

131. goodapi.co
     ATTACKING THE COMPLEXITY WITH
     AUTONOMY
     Self-driving
     Clients
     Clients can self-
     navigate the API
     landscape,
     perform self-
     configuration, self-
     repair, self-
     optimization and
     make choices at
     various decisions
     points
     automatically
     High-level,
     declarative
     programming
     Reducing the
     cognitive algorithmic
     complexity,
     decoupling from
     components
     implementation,
     programming for
     domain, not service
     Automated,
     contract-driven API
     lifecycle
     Handling API
     provider complexity
     by keeping,
     versions,
     implementations
     and deployments in
     check
     Hierarchical and
     context-bound
     knowledge
     Divide and conquer
     size complexity with
     domain definitions
     and bounded
     contexts. Reusable
     representation of
     domain knowledge–
     ontologies–
     published language
     

     View Slide

132. goodapi.co
     WHAT WOULD MYSTAY DO?
     • Define Hospitality Domain
     • Define Hotel Room subdomain
     • “Train" MyStay Mobile app for the subdomain 

     

     if (room.roomService.available)

     display room.roomService.offer

     

     if (room.ac.available)

     display acControls

     • Deploy mobile clients
     • Provide IoT integration components-hubs for hotels
     

     View Slide

133. goodapi.co
     GOOD
     API
     INDEPENDENT API CONSULTING
     

     View Slide

134. IMAGES BY UNSPLASH.COM
     

     View Slide

135. goodapi.co
     BACKUP
     

     View Slide

136. goodapi.co
     COMPLEXITY OF
     DISTRIBUTED
     COMPUTING SYSTEMS
     https://www.ideals.illinois.edu/handle/2142/11022
     

     View Slide

137. goodapi.co
     AUTONOMOUS APIS
     • Self-driving clients
     • Navigation in landscape
     • Self-configuration
     • Resilience & Self-repair
     • Self-optimization
     • Self-decision making
     • High-level, declarative programming of the clients
     • Hierarchical and context-bound knowledge
     • Automated, contract driven API lifecycle
     

     View Slide

138. goodapi.co
     COMPLEXITY OF
     DISTRIBUTED
     COMPUTING SYSTEMS
     • How understandable a system is
     • How difficult it is to perform
     tasks in the system
     • Business tasks
     • Maintenance tasks
     • Change tasks (cost of making
     changes)
     • High complexity
     • High costs
     • High and reaction times
     • Low performance
     • High mental and cognitive
     effort to navigate and use
     • Fault-prone
     • Prevent evolution
     

     View Slide

139. goodapi.co
     THE NUMBER OF CLIENTS
     BROUGHT PROBLEMS WITH
     COMMUNICATING API DESIGN
     CHANGE, REACTING TO IT AND
     EVOLVING APIS
     

     View Slide