Autonomous APIs - Speaker Deck

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

goodapi.co THE WAVES OF API TRANSFORMATION

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

goodapi.co goodapi.co GENERIC APIS Second Wave

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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)

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

goodapi.co goodapi.co HARMONIZED APIS Third Wave

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

goodapi.co

Slide 26

Slide 26 text

goodapi.co

Slide 27

Slide 27 text

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)

Slide 28

Slide 28 text

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?

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

goodapi.co

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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)

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

goodapi.co IOT

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

goodapi.co COMPLEXITY

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

goodapi.co SOLUTIONS

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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?

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

goodapi.co TOOLS ARE OUR LIMITS

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

goodapi.co API LANDSCAPES APIs are no longer in silos

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

goodapi.co 5 LEVELS OF AUTONOMY

Slide 78

Slide 78 text

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)”

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

goodapi.co BUILDING BLOCKS OF AUTONOMOUS APIS

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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.

Slide 88

Slide 88 text

goodapi.co Level 3 Decoupled Automated System 3

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

goodapi.co ENGINEERING PRINCIPLE OF GENERALITY 1957 2018

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

Slide 93

Slide 93 text

goodapi.co UNIFORM INTERFACE HAS MANY BENEFITS • Simpliﬁes 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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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 -

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

goodapi.co Level 4 Autonomous System 4

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

goodapi.co DATA MODELS & VOCABULARIES, ONTOLOGIES

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

goodapi.co LINKED DATA - SEMANTICS FOR HUMANS & MACHINES

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

goodapi.co SHARED VOCABULARIES

Slide 118

Slide 118 text

goodapi.co https://supermodel.io

Slide 119

Slide 119 text

goodapi.co PROGRAM FOR VOCABULARY NOT DATA STRUCTURE

Slide 120

Slide 120 text

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’) }

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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)

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

goodapi.co ATTACKING THE COMPLEXITY WITH AUTONOMY

Slide 131

Slide 131 text

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 deﬁnitions and bounded contexts. Reusable representation of domain knowledge– ontologies– published language

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

goodapi.co GOOD API INDEPENDENT API CONSULTING

Slide 134

Slide 134 text

IMAGES BY UNSPLASH.COM

Slide 135

Slide 135 text

goodapi.co BACKUP

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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