Autonomous APIs (O’Reilly Software Architecture 2019)

https://conferences.oreilly.com/software-architecture/sa-eu/public/schedule/detail/79145

Services with their APIs are no longer living isolated in silos. Capabilities exposed by these microservices, service meshes, and serverless functions are creating the landscapes. The clients depend on multiple services and are often servers to other clients. These landscapes are forming at every level—team, application, organization, domain, and global—are starting to face out-of-the-bound complexity issues. The current approach to building such systems is imperative programming, human-produced and consumed interface documentation, minimal visibility, and limited automation (“Do you CI? Do you even CD?”). As such, it’s impossible to predict the effects of modifying even one component of the system. The task structure and size complexity is growing beyond our cognitive abilities, and yet we’re still trying to solve the problem by hiring more engineers.

With limited visibility, the capability discovery in these landscapes is limited to institutional knowledge, hand-crafted organizational Wiki pages, or Google searches on the domain and global level. Zdenek Nemec explores the problems with the complexity of forming API landscapes and proposes the autonomy of the components as the solution to the difficulty of managing components centrally. He defines levels of autonomy and examines the building blocks of autonomous systems such as automation, virtualization, uniform interface, bounded context, domain-driven design, declarative programming, semantic profiles, service discovery, and self-driving clients. He also gives special attention to the interface lifecycle, advertising future changes and subscription to it. He details the most important and currently missing piece—the service discovery (API producing and consuming standpoint, not the DevOps virtual machine (VM) and machine instance).

Transcript

1. goodapi.co
   Autonomous APIs
   The next chapter begins
   

   View Slide

2. goodapi.co
   supermodel.io
   

   View Slide

3. goodapi.co
   Pleasure to meet you!
   Networking encouraged
   Let’s spend a couple of minutes introducing ourselves to the people next
   to us, say what company or organization you are from, and what you are
   looking to learn from this session.
   

   View Slide

4. goodapi.co
   Autonomous Cars
   source: https://www.bmw.com/en/automotive-life/autonomous-driving.html
   

   View Slide

5. goodapi.co
   Autonomous APIs?
   

   View Slide

6. goodapi.co
   How can we have autonomous
   cars but not autonomous APIs?
   

   View Slide

7. goodapi.co
   API styles over time
   REST vs. GraphQL
   @zdne
   

   View Slide

8. goodapi.co
   Interest over time
   

   View Slide

9. goodapi.co
   BREAKTHROUGH
   ANNOUNCEMENT
   Paradigm Shift
   1. CUSTOMER-SPECIFIC APIS 2. GENERIC APIS 3. HARMONIZED APIS 4. AUTONOMOUS APIS
   one-to-many
   one-to-one many-to-many machine-to-machine
   l
   C
   P l
   C
   P
   l
   C
   l
   C
   l
   C
   P
   l
   C
   l
   C
   P
   P
   l
   C
   P
   l
   C
   l
   C
   P
   P
   3P
   

   View Slide

10. goodapi.co
    goodapi.co
    EVERY CHAPTER
    HAS ITS API
    ARCHITECTURAL
    STYLE–API –
    PARADIGM
    

    View Slide

11. goodapi.co
    Customer-specific
    APIs
    • Large organizations embracing IT
    • years 1990-2000s
    • SOAP, EDI, FTP & ESB
    • one-to-one, point-to-point
    1. CUSTOMER-SPECIFIC APIS
    one-to-one
    l
    C
    P
    

    View Slide

12. goodapi.co
    Problems
    • API providers face issues with size
    complexity of point to point
    integrations and the ESB “failure”
    • New API consumers find the APIs too
    complex and cumbersome to use
    • New API consumers often ignored or
    misunderstood, and over/under
    served by SOAP API providers
    1. CUSTOMER-SPECIFIC APIS
    one-to-one
    l
    C
    P
    

    View Slide

13. goodapi.co
    Generic APIs
    one-to-many: many mid- or
    small- size customers
    one-to-one: few large
    established customers
    l
    C
    P l
    C
    P
    l
    C
    l
    C
    

    View Slide

14. goodapi.co
    Generic APIs
    • Ubiquitous internet & software
    development
    • years 2005-2019+
    • so-called-REST, later also GraphQL
    • one-to-many
    2. GENERIC APIS
    one-to-many
    l
    C
    P
    l
    C
    l
    C
    

    View Slide

15. goodapi.co
    Problems • API providers are facing complexity
    issues from increasing number of own
    APIs, client integrations, server &
    client deployments and api versions
    • New consumers find complex and
    costly to integrate and maintain the
    integrations with multiple different
    apis
    • API consumers often ignored or
    misunderstood, and over/under
    served by Fragmented, siloed APIs and
    its providers
    2. GENERIC APIS
    one-to-many
    l
    C
    P
    l
    C
    l
    C
    

    View Slide

16. goodapi.co
    Harmonized APIs
    many-to-many: clients
    consuming multiple APIs
    one-to-many: many mid- or
    small- size customers
    l
    C
    P
    l
    C
    l
    C
    l
    C
    P
    l
    C
    l
    C
    P
    P
    3P
    

    View Slide

17. goodapi.co
    API
    Landscapes
    APIs are no longer in silos
    goodapi.co
    

    View Slide

18. goodapi.co
    HARMONIZED APIS
    one-to-many
    Organizations landscapes
    

    View Slide

19. goodapi.co
    HARMONIZED APIS
    one-to-many
    Organizations landscapes
    

    View Slide

20. goodapi.co
    HARMONIZED APIS
    B C D . . .
    If I am building an e-shop do I want to integrate with 400
    logistics providers?
    e-shop
    Domain Landscapes
    

    View Slide

21. goodapi.co
    Harmonized APIs Examples
    

    View Slide

22. 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

23. 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

24. goodapi.co
    Client Client Client Client Client Client
    Hospitality & Travel
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    

    View Slide

25. 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

26. 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

27. goodapi.co
    goodapi.co
    How are incumbents loosing
    contact with their customers
    

    View Slide

28. 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

29. 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

30. goodapi.co
    Incumbent
    Existing
    Customer
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    First chapter customers moving to 3rd Party
    

    View Slide

31. goodapi.co
    Unable to adapt to the
    incumbents are loosing their
    positions to disruptors
    

    View Slide

32. 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

33. 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

34. goodapi.co
    How to integrate with thousands of IoT devices from
    different vendors deployed in different environments?
    

    View Slide

35. goodapi.co
    IOT
    

    View Slide

36. goodapi.co
    goodapi.co
    Multiple
    Domains
    The situation is
    even worse when
    you consider…
    

    View Slide

37. goodapi.co
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    API
    Consumer
    APIs
    Accommoda
    tion B
    Accommoda
    tion E
    consuming multiple APIs
    Cross-domain
    

    View Slide

38. goodapi.co
    Accommoda
    tion B
    Accommoda
    tion C
    Accommoda
    tion D
    Accommoda
    tion E
    Customer
    3rd party
    consuming multiple APIs
    Cross-domain
    

    View Slide

39. goodapi.co
    Universe of capabilities
    This is what Amazon (Alexa skills), Google
    (Home skills) & VIV (Samsung) are doing.
    Database of knowledge and services with uniform interface
    

    View Slide

40. goodapi.co
    Harmonized APIs • Clients consuming multiple APIs
    • Micro-services, forming API
    landscapes
    • Year 2017+
    • Complexity of consuming multiple
    different APIs is tackled by
    standardization, design governance to
    achieve consistency
    • Harmonization is also often done with
    “wrapper” APIs
    3. HARMONIZED APIS
    many-to-many
    l
    C
    P
    l
    C
    l
    C
    P
    P
    3P
    

    View Slide

41. goodapi.co
    Problems
    • Harmonized APIs providers are facing
    complexity issues trying to normalize,
    govern or maintaining many
    integrations APIs manually
    • Harmonization, standardization &
    governance complexity tackled by
    automation
    • Complexity external API consumers
    are facing when consuming multiple
    domain or cross-domain APIs is still
    left unchecked
    3. HARMONIZED APIS
    many-to-many
    l
    C
    P
    l
    C
    l
    C
    P
    P
    3P
    

    View Slide

42. goodapi.co
    Complexity
    

    View Slide

43. goodapi.co
    COMPLEXITY
    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

44. goodapi.co
    COMPLEXITY
    API Designs x Versions x Deployment Hosts x Clients x Client Deployments
    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
    IF THE NUMBER OF
    

    View Slide

45. goodapi.co
    Cost of Change
    6,1% chance of breaking change every day (java library)
    

    View Slide

46. goodapi.co
    Solutions
    

    View Slide

47. goodapi.co
    SOLUTIONS TO COMPLEXITY
    1. Hire more people
    2. Standardization
    3. Automation
    4. Autonomy of the components
    

    View Slide

48. goodapi.co
    Solutions to complexity
    1. Hire More People
    Mechanical turks, eyeballing documentation for changes
    in design, fixing clients and implementations accordingly.
    CUSTOMER-SPECIFIC & GENERIC APIS
    ROLE OF HUMANS IN APIS
    

    View Slide

49. goodapi.co
    MACHINE EXPOSES
    INTERFACE
    ANOTHER MACHINE
    LEARNS & USES
    INTERFACE
    MACHINES MEET
    OVER THE NETWORK
    discovery
    What we think API is
    Hire more people
    

    View Slide

50. goodapi.co
    Hire more people
    Reality
    MACHINE EXPOSES
    INTERFACE
    ANOTHER HUMAN
    READS
    DOCUMENTATION
    HUMAN WRITES
    DOCUMENTATION
    ANOTHER MACHINE IS
    TAUGHT TO USE
    INTERFACE
    HUMANS MEET
    discovery
    
    
    
    
    
    

    View Slide

51. goodapi.co
    Hire more people
    Reality
    
    
    
    
    
    
    HUMANS INSIDE
    VS.
    • time and money spent
    • not scaling
    • chance of
    misinterpretation
    • error-prone
    

    View Slide

52. goodapi.co
    SOLUTIONS TO COMPLEXITY
    2. Standardization
    HARMONIZED APIS
    API DESIGN, LIFECYCLE &
    DEVELOPMENT STANDARDIZATION
    

    View Slide

53. goodapi.co
    Standardization
    Product consistency
    

    View Slide

54. goodapi.co
    Standardization
    API Guidelines & design checks
    

    View Slide

55. goodapi.co
    3. Automation
    AUTOMATED HARMONIZED APIS
    Solutions to complexity
    AUTOMATED CONTRACT-DRIVEN API
    LIFECYCLE
    

    View Slide

56. goodapi.co
    Automation
    
    
    
    INTERFACE
    ACTUALLY
    EXPOSED
    INTERFACE
    DOCUMENTED
    INTERFACED
    USED
    are they the same?
    are they the same?
    are they the same?
    Keeping things in check is hard
    

    View Slide

57. goodapi.co
    Contract-driven
    Automation
    

    View Slide

58. goodapi.co
    https://goodapi.co/api-lifecycle
    Automation
    Entire lifecycle
    

    View Slide

59. goodapi.co
    Tools are our limits
    

    View Slide

60. 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

61. goodapi.co
    4. Autonomy
    AUTONOMOUS APIS
    AUTONOMY IS THE SOLUTION TO THE DIFFICULTY
    OF MANAGING MANY COMPONENTS CENTRALLY
    Components autonomy in an API Landscape reduces the
    complexity, enables scaling, and promotes the service
    commoditization.
    Solutions to complexity
    

    View Slide

62. goodapi.co
    Autonomy
    “Autonomy: freedom from external control or influence;
    independence; sovereignty in making decisions and
    changes.”
    –New Oxford American Dictionary
    

    View Slide

63. 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

64. goodapi.co
    Autonomous APIs
    • Machine-to-machine APIs, self-driving,
    no human intervention, cross-domain
    landscapes
    • Rise of IoT & AI
    • Year 2020+
    4. AUTONOMOUS APIS
    machine-to-machine
    l
    C
    P
    l
    C
    l
    C
    P
    P
    

    View Slide

65. goodapi.co
    Autonomous APIs
    1. Consuming more than one API
    2. Cross-domain
    3. Demanding reduction of complexity
    4. Self-driving in API Landscape
    5. Autonomous-decoupled from particular API provider
    NEXT-GEN CONSUMERS
    

    View Slide

66. goodapi.co
    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
    Autonomous APIs
    Navigate safely in API landscape
    

    View Slide

67. goodapi.co
    5 Levels of
    Autonomy
    goodapi.co
    

    View Slide

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

    View Slide

69. goodapi.co
    Levels of Autonomy
    Autonomy
    Autonomous APIs
    Brittle System
    Documented Brittle System
    Automated System
    Decoupled Automated System
    Autonomous System
    1
    2
    3
    4
    5
    

    View Slide

70. goodapi.co
    Level 1:
    Brittle system
    • 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
    Level 1
    

    View Slide

71. goodapi.co
    Level 2:
    Documented Brittle
    System
    • 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
    Level 2
    

    View Slide

72. goodapi.co
    Level 3:
    Automated system
    • 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
    Level 3
    

    View Slide

73. goodapi.co
    Level 4:
    Decoupled
    automated system
    • Uniform Interface
    • Decoupled components
    • Evolvability of the components in their
    respective environments
    • Share understanding-metadata at
    RUNTIME
    • Pros
    • Harmonized within the system
    • Reducing price and risk of making
    changes (by design)
    • Cons
    • No machine autonomy
    • Difficult taking everything into
    account, prone to chaotic & size
    complexity
    Level 4
    

    View Slide

74. goodapi.co
    Building blocks
    Level 4
    Decoupled Automated System
    4
    

    View Slide

75. goodapi.co
    Building block 1/3
    Uniform
    Interface
    A consistent, predictable way to
    query data and exercise actions
    regardless of the service provider
    

    View Slide

76. goodapi.co
    Uniform interface
    1957 2018
    Engineering principle of generality
    

    View Slide

77. goodapi.co
    Engineering Principle of Generality
    

    View Slide

78. goodapi.co
    Uniform interface
    Engineering principle of generality
    Existing
    Customer
    Existing
    Customer
    3rd party
    New Type of
    Customer
    New Type of
    Customer
    New Type of
    Customer
    Provider Provider Provider
    Uniform Interface
    to incumbents
    B C D
    e-shop
    3rd party
    

    View Slide

79. goodapi.co
    Benefits of UI
    Engineering principle of generality
    • 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

80. 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

81. goodapi.co
    Path To Uniform interface
    1. Apply Modern Architectural Styles (REST) and Linked Data (JSON-LD)
    2. “Wrapper APIs”, build or leave it up to 3rd Party Vendors (Metapack,
    Amazon, Google..) to become the intermediaries to the universe
    3. Autonomous APIs (coming later)
    

    View Slide

82. goodapi.co
    Do you want to provide an uniform interface or leave it to third-party
    vendor to do it?
    Client Client Client Client Client Client
    Provider Provider Provider
    Client Client Client
    Linked Data & Architecural Style
    Client Client Client
    Provider Provider Provider
    - OR -
    Building your next API
    

    View Slide

83. goodapi.co
    Building block 2/3
    Decoupled
    components
    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
    Abstraction
    Layer
    Comp-A Comp-B
    

    View Slide

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

    View Slide

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

    View Slide

86. goodapi.co
    Building block 3/3
    Understanding
    shared at runtime
    • Available HATEOAS state transitions
    • HAL, Siren, RESTful JSON
    • Non-authoritative parameter validations
    • JSON Schema, Code on Demand
    • API Description - map
    • OpenAPI Specification, API Blueprint …
    • GraphQL Schema
    

    View Slide

87. goodapi.co
    Level 5:
    Autonomous
    System
    • Self driving clients
    • Landscape discovery
    • Machine understanding
    • Vocabulary not data structure
    • Declarative programming
    • Autonomy of the components
    • Leveraging learned data from simulation for
    infrastructure
    • Pros
    • Higher level of abstraction
    • Implicit harmonization
    • Full autonomy of components
    • Independent evolution
    • Cons
    • Cognitive (Algorithmic) Complexity
    • Demanding on computational power
    • Higher level of abstraction
    Level 5
    

    View Slide

88. goodapi.co
    Building blocks
    Level 5
    Autononomous System
    5
    

    View Slide

89. goodapi.co
    Building block 1/3
    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

90. goodapi.co
    Building block 2/3
    Machine
    understanding
    Protocol
    Message
    Application
    HTTP Protocol Semantics
    Message Format Semantics (e.g. HAL)
    Application Domain Semantics
    (e.g. Hospitality domain)
    Program for vocabulary
    not data structure
    

    View Slide

91. goodapi.co
    Data models & vocabularies,
    ontologies
    

    View Slide

92. goodapi.co
    Canonical data
    model is anti-pattern
    goodapi.co
    in modern systems architecture
    

    View Slide

93. goodapi.co
    Domain-Driven Design
    Divide and conquer complexity by bounded context and context mapping
    images from
    Domain-Driven-Distilled
    

    View Slide

94. goodapi.co
    Context Mapping
    images from
    Domain-Driven-Distilled
    

    View Slide

95. goodapi.co
    Linked data - semantics for
    Humans & machines
    

    View Slide

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

    View Slide

97. goodapi.co
    Shared vocabularies
    

    View Slide

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

    View Slide

99. goodapi.co
    Program for vocabulary
    NOT
    Data Structure
    

    View Slide

100. goodapi.co
     Program for Vocabulary
     // Programming for data structure
     display todo.title
     // Programming for vocabulary
     if (todo.has('title')) {
     display todo(‘title')
     }
     

     View Slide

101. goodapi.co
     JSON-LD (linked data)
     {
     "@context": "https://json-ld.org/contexts/person.jsonld",
     "@id": "http://dbpedia.org/resource/John_Lennon",
     "name": "John Lennon",
     "born": "1940-10-09",
     "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
     }
     https://json-ld.org
     

     View Slide

102. goodapi.co
     Hydra
     JSON-LD meets HATEOAS
     http://www.markus-lanthaler.com/hydra/console/
     

     View Slide

103. goodapi.co
     ALPS Profile
     Application-Level Profile Semantics (ALPS)
     http://alps.io
     

     View Slide

104. goodapi.co
     Building block 3/3
     Autonomous
     service
     discovery MACHINE EXPOSES
     INTERFACE
     ANOTHER MACHINE
     LEARNS & USES
     INTERFACE
     MACHINES MEET
     OVER THE NETWORK
     discovery
     

     View Slide

105. goodapi.co
     Yahoos of API World
     Global Landscapes
     • Rapid API
     • Any API
     • APIS.json
     • Hitch HQ (acquired)
     • GraphQL Hub
     Internal Landscapes
     • Internal Developer Portals
     • API Repositories (Apiary,
     SwaggerHub)
     Human-only, hand picked
     

     View Slide

106. goodapi.co
     Micro service discovery
     • Netflix Zulu / Eureka
     • Apache / Kafka / Zookeper
     • Hashicorp / Consul
     • Linkerd
     No API Landscape Metadata discovery Services
     

     View Slide

107. goodapi.co
     But these are not enough
     We need publish-subscribe model for API
     Landscape and API discovery
     

     View Slide

108. goodapi.co
     Autonomous service discovery
     “Registry, look for a service that knows weather in Paris.”
     “Registry, look for a service that can fulfill the shipment of 6 pallets
     from Prague to Paris.”
     “Registry, look for a service that can play every movie by the director
     of movie Avatar.”
     

     View Slide

109. goodapi.co
     Autonomous service discovery
     // 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

110. goodapi.co
     Building blocks of Autonomous APIs
     Level 5
     Autonomous System
     Level 4
     Decoupled Automated System
     • Declarative programming
     • Machine understanding
     • Autonomous discovery
     4
     3 • Uniform Interface
     • Decoupled components
     • Autonomous navigation
     

     View Slide

111. 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

112. goodapi.co
     

     View Slide

113. goodapi.co
     API Chapters
     one-to-many
     one-to-one
     many-to-many
     machine-to-machine
     Drivers behind the changes
     API CONSUMERS EXPECTATIONS COMPLEXITY
     task-structure
     unpredictability
     chaotic
     size
     algorithmic
     +
     GROWING # OF
     API CONSUMERS
     +
     INCREASING DEMAND EVOLVING DEMAND INCREASING PROBLEMS
     

     View Slide

114. goodapi.co
     1. CUSTOMER-SPECIFIC APIS 2. GENERIC APIS 3. HARMONIZED APIS 4. AUTONOMOUS APIS
     one-to-many
     one-to-one many-to-many machine-to-machine
     API Chapters
     

     View Slide

115. goodapi.co
     Digital wholesale presence & service
     commoditization
     “Look for a service that can fulfill the shipment of 6
     pallets from Prague to Paris under 100 EUR.”
     “Look for a service that provides information about
     adidas stan smith”
     “Is there an air condition service in my landscape?”
     “Look for a service that has gs1:Offer where
     gs1:itemOffered gs1:gpcCategoryCode is MILK.”
     “The level of autonomy is the
     ability to safely navigate in the API
     landscape (where the constraints
     are time and price)”
     

     View Slide

116. superface.io
     Commoditization
     CUSTOMER SPECIFIC APIS (SOAP)
     GENERIC APIS (SO-CALLED-REST)
     HARMONIZED APIS
     AUTONOMOUS APIS
     HARMONIZED APIS (AUTOMATED)
     Graph by Simon Wardley,
     “How commodity is
     something?”
     

     View Slide

117. goodapi.co
     

     View Slide

118. IMAGES BY UNSPLASH.COM
     ICONS BY MARTINFOWLER.COM
     

     View Slide

119. 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