API Development: Evolving Prospects and Future Outlook

Transcript

1. API Development: Evolving Prospects and Future Outlook 1
2. codecentric AG Hoher Wall 15 44137 Dortmund Telefon: +49 (0) 151. 10 86 70 74 Daniel Kocot Head of APIConsulting AsyncAPI Ambassador Team Topologies Ambassador daniel.kocot@codecentric.de https:/ /www.codecentric.de/standorte/dortmund/dortmund-tea m#daniel-kocot https:/ /danielkocot.github.io Innovative - Trustful - Competent - Pragmatic 2
3. Selfie time! 4
4. API Development 11
5. Definition 12 DEFINITION CREATION IMPLEMENTATION TESTING AND DEBUGGING DOCUMENTATION AND DEPLOYMENT
6. Why do organisations invest in API Development? 13
7. Why do organisations invest in API development? 14 Costs, turnover, growth Automation, Better time to market Added value from data Regulation Benefiting from new technologies
8. API Development is a key driver in the context of transformation. 15
9. Continuous (Application) Transformation 16
10. API first 17
11. API first 18 PRIORITISING APIS WITHIN THE ORGANISATION APIS BECOME A MAIN PART OF THE BUSINESS MODEL OF THE ORGANISATION API FIRST IS NOT A PARADIGM FOR YOUR DEVELOPMENT TEAM!
12. API as a Product API Product 19
13. Definition 20 VALUE PROPOSITION ANALYTICS AND MAYBE SOME KIND OF MONETISATION OWNERSHIP AND LIFECYCLE MANAGEMENT DOCUMENTATION AND DEVELOPER EXPERIENCE
14. But an API is not the panacea 21
15. APIs are not the panacea 22 In some situations they are not the best fit Security Dependencies Complexity
16. Integration 23
17. Application Integration 24
18. Application Integration 25 DISTRIBUTION OF DATA AND INFORMATION BETWEEN APPLICATIONS ENTERPRISE INTEGRATION PATTERNS
19. Data Integration 26
20. Data Integration 27 DISTRIBUTION OF DATA BETWEEN DATA STORES EXTRACT, TRANSFORM, LOAD (ETL) CHANGE DATA CAPTURE(CDC)
21. Unfortunately, APIs serve as the medium for data transmission. 28
22. How dull! But we all adore technology! 29
23. Thus, discussions about designing APIs morph into Kafkaesque, technology-driven dialogues. 30
24. Content of technology-driven dialogues 31 HTTP/REST SOAP Kafka GraphQL
25. But generally, that doesn’t address any customer needs 32
26. Stop immediately! 33
27. Let’s get things right from the start! 34
28. Data 35
29. Daily Routine: Searching for data and creating new value for the organisation 36
30. Discovery of Data 37
31. Awareness of Data Products and Data Contracts 38
32. Data what? 39
33. Data Product 40 VALUE DRIVEN OUTPUT USER INTERACTION CROSS-DISCIPLI NARY DEVELOPMENT MONITORING AND MAINTEANCE
34. Data Product – Schematic View 41
35. Data Contract 42 FORMAL AGREEMENT SCHEMA DEFINITION DATA GOVERNANCE INTERFACE SPECIFICATION
36. More Details 43
37. Only data products that add value can lead to equally valuable API products. 44
38. Focus on Developer Success 47
39. Data Contracts as the Foundation 48
40. However, API descriptions require data schemas/models. 49
41. Generate data models from data contracts. 50
42. APIs 51
43. Every API is driven by the need to access data. 52
44. Two questions need to be addressed. 53
45. There are two questions to answer. 54 WHO IS INTERESTED IN ACCESSING THE DATA? WHY DO THEY WANT TO ACCESS DATA?
46. Everything we do now is becoming consumer-centric 55
47. API Thinking 56
48. Classical Design Thinking 57 Empathise Define Ideate Prototype Test
49. API Development API Thinking 58 Empathise with stakeholders Data definition API definition API endpoint and backend implementation Test by stakeholders
50. In the following, we will focus solely on API products. 59
51. Three dimensions of API development 60
52. Design first 61
53. Design first Principles 62 Planning before coding Collaboration Early Validation Consistency and Standardization
54. Code first 63
55. Code first Principles 64 Development approach Automatic Documentation Generation Flexibility and Speed
56. Prototype first 65
57. Prototype first Principles 66 Early visualisation Feedback collection Cost efficiency Faster iterations
58. API Interaction Patterns 67
59. Definition 68 Different API interaction patterns exist to accommodate various use cases, requirements, and preferences of API consumers. These pattern provide different ways for clients to interact with APIs and can be chosen based on factors such as the nature of the application the desidered level of control and flexibility, and the specific goals of the API design
60. Overview 69 Resource / Hypermedia Tunnel Query Event-Based
61. Resource / Hypermedia 70 EXECUTE A SPECIFIED SET OF METHODS ON REMOTE RESOURCES. HTTP, ODATA, GRPC
62. Tunnel 71 CALL A PROCEDURE/COMMAND ON A REMOTE SERVER AS YOU WOULD LOCALLY CALL A FUNCTION IN YOUR PROGRAMMING LANGUAGE SOAP, XML/JSON-RPC,GRPC, ODATA
63. Query 72 FORMULATE A QUERY AGAINST A REMOTE DATASET AS IF THE API WERE A DATABASE (CF. SQL) HTTP (QUERY), ODATA, GRAPHQL
64. Event-Based 73 FETCH EVENTS COMING TO AND FROM MESSAGE BROKER AMQP, MQTT, CLOUDEVENTS
65. The goal of API development is essentially to deploy a service along with an API. 74
66. However, developers don't want to deal with YAML or JSON files. 75
67. These should merely be artefacts created by automated processes. 76
68. First Idea 77
69. Code-first approach based on the generated data model 78
70. Beneficial Impacts 79 THE DEVELOPMENT TEAM CAN STICK TO ITS STACK. THE API DEFINITION IS GENERATED BY THE FRAMEWORKS BEING USED.
71. Adverse Impacts 80 TEAMS ON BOTH THE PROVIDER AND CONSUMER SIDES CANNOT DEVELOP CONCURRENTLY. THE LIBRARY USED TO GENERATE THE DEFINITION DOESN'T FULLY SUPPORT THE ENTIRE FEATURE SET OF THE SPECIFICATION.
72. Second Idea 81
73. Interface first 82
74. Interface first 83 FOUNDED ON DESIGN FIRST PRINCIPLES DEFINING ENDPOINTS VIA PROGRAMMATIC, TYPE-SAFE, AND PLATFORM-AGNOSTI C INTERFACES OPPORTUNITY TO CONSOLIDATE ALL OUTPUT PORTS OF A DATA PRODUCT WITHIN A SINGLE INTERFACE DESCRIPTION. ADAPT THIS INTERFACE DESCRIPTION BASED ON THE PROVIDED API INTERACTION PATTERNS. IMPLEMENT THE SERVICES USING THE SUPPORTED PATTERNS, ALIGNING WITH THE PROGRAMMING EXPERTISE OF EACH TEAM.
75. Introduction to new (additional) tooling 84
76. Interface First Tooling 85 Microsoft TypeSpec TaxiLang Fern
77. Microsoft TypeSpec 86
78. Description 87 Build a first to serve a s a language for describing cloud service APIs Ability to facilitate the generation of other API description languages Provides extensible core language primitives to describe API shapes Evolving language so breaking changes can still happen
79. Microsoft TypeSpec 88
80. Microsoft TypeSpec 89
81. Interface first at a glimpse 90 Beginning with a data model supported by Data Products and Data Contracts Describe the interfaces for a data model in a programmatic and type-safe manner. Available solutions so far: Microsoft TypeSpec, TaxiLang, Fern
82. APIOps 91
83. Focus on Developer and Business Success 92
84. The idea of APIOps 93
85. API Operations Pipeline first iteration 2020 94
86. API Operations Pipeline Second Iteration 95 •Bundling of Definition Prepare •Use of Linters •Redocly for generic structure •Spectral or Vacuum for specific rules, like org-related and OWASP Top 10 •Check for Break Changes with oasdiff Validate •Contract Testing •Using Prism for Mocking •Testsuite covered by Portman and Newman Test •Deploying the definition to an API Gateway including needed transformations Deploy •Publishing the definition and additional information to an IDP and/or Marketplace Publish
87. Conclusion 98
88. Conclusion 99 API Development is a challenging and demanding task. Tooling always complements the underlying methodology. Initially, an API Management solution is not required for the development of APIs. To create high-quality APIs, adhere to standards and incorporate concepts from Data Mesh.
89. 100 codecentric AG | Hochstraße 11 | 42697 Solingen Creating the digital future together. Thank you!
90. References 101 Cover Slide: Photo by Drew Beamer on Unsplash Slide 48: Photo by Emily Morter on Unsplash Slide 12: Photo by Franki Chamaki on Unsplash Slide 19: Photo by NASA on Unsplash Slide 21: Photo by Markus Winkler on Unsplash Slide 24: Photo by Sandro Gonzalez on Unsplash Slide 33: Photo by N. on Unsplash Slide 34: Photo by Dimitri Karastelev on Unsplash Slide 55: Photo by Aditya Chinchure on Unsplash Slide 91: Photo by Clay Banks on Unsplash