Upgrade to Pro — share decks privately, control downloads, hide ads and more …

apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet, UMLTech

apidays
January 05, 2023

apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet, UMLTech

apidays Paris 2022 - APIs the next 10 years: Software, Society, Sovereignty, Sustainability
December 14, 15 & 16, 2022

Generating APIs from business models: high productivity and consistency
Frederic Fontanet, Architect / API designer at UMLTech
------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Deep dive into the API industry with our reports:
https://www.apidays.global/industry-reports/

Subscribe to our global newsletter:
https://apidays.typeform.com/to/i1MPEW

apidays

January 05, 2023
Tweet

More Decks by apidays

Other Decks in Programming

Transcript

  1. 2023 SERIES OF EVENT New York May 16&17 Australia October

    11&12 Singapore April 12&13 Helsinki & North June 5&6 Paris SEPTEMBER London November 15&16 June 28-30 SILICON VALLEY March 14&15 Dubai & Middle East February 22&23
  2. Business and technical stakeholders  GAP APIs: issues on ‘traditionnal’

    design Complexity of http rules, patterns and API conventions Lack of diagrams to discuss about the business concepts Lack of consistency of the entity definitions
  3. 4 Which way for a business approach? Provided operations Whishing

    that … Business requirements Exposed resources Customer journey
  4. 5 ‘’We need 50 business analysts knowing HTTP or 50

    API designers knowing business’’ subsidiary Product owners and API designers gap
  5. 6 Increase abstraction Increasing automation and consistency at the entreprise

    level involves increasing abstraction (formal models / grammars)
  6.  Provides diagrams  Allows Object Oriented Design  Very

    good feed-back and involvements from business stakeholders  Provides METADATA  UML is a standard  Matches many of the API design requirements 7 UML Model as a (business) formal model
  7. 8 UML coverage of OAS (v3.x) Features Schemas Objects concepts

    (polymorphism, inheritance…) Operations Servers Paths (endpoints) - Parameters / request body / header parameters Responses Links Callbacks Examples Security -
  8. Technical design HTTP specifications Security Infra Business Requirements Scenarios (narrative

    use cases) Business requirements Use cases identification Formal Models Contracts Definitions (structural schémas) Functional design APIs: a Business and Enterprise approach Totally API first approach
  9. From the use cases to the model 1) Decompose the

    business process 2) Remove irrelevante steps … 12) Valid the operations Candidates ‘services’ Business use case From the requirements and business processes… … services items are identified (operations, entities, properties, rules) … then derived into concrete ‘APIs’ (UML models) APIs in the model
  10. 12 Need of consistency 50 API designers (no automatisation, a

    dedicated reviewer team) 2 API designers, no reviewer team
  11. One model to rule them all Schema Avro To be

    coming One global enterprise business data model
  12. 14 API FinancialProduct API Mobility quotation API Retail quotation API

    Context sharing A business data entity is designed once for all APIs (enterprise level) Then, the relative schema(s) is(are) taylored for each API Consistency on schemas Diagrams are intentionally blurred
  13. 16 Tayloring a schema Select the properties for an API

    Take into account … or not …the new properties Text is intentionally blurred
  14. 17 API #2 API #4 API #3 API #1 A

    business data entity is designed once for all APIs (enterprise level) Then, the relative schema(s) is(are) taylored for each API Update / add / remove a property
  15. 24 Productivity: creating operations and parameters Functional design Operations from

    a business view Technical design http and security design YAML
  16. 26 Governance: roles (analysis to design) Business experts Product owner

    Business experts functional designers API Designers UML models 30 to 35% 1 to 5% 60 to 65%
  17. 27 Conclusion  Think business … not technical design 

    Increase abstraction  models (UML, specific DSL)  Apply patterns  Automate the transformation from the models to the APIs  Tools:  Any UML Modeler (based on EMF) 
  18. 30 Swapi in a nutshell o Designed for designing at

    the enterprise level, and to focus on business o Help to improve the abstraction and the reusability o X30 to x50 faster than regular tools, with less errors and higher consistency (intra and inter apis) o HTTP Rules engine (fix errors) o Versioning + comparator of versions o Full coverage of the OpenAPI specifications o Schemas / security / HATEOAS / Callbacks / Headers… o Still in development (> 200 000 lines of codes) but already operational in a major french bank
  19. Use cases: Narrative use case  writing the functional solution

    One nominal scenario A set of alternatives A set of extensions
  20. Applying patterns • A pattern provides a proven solution to

    a common problem o API and µ-services patterns  https://patterns.arcitura.com/ CQRS pattern
  21. APIs: from requirements to code … (personal) actual observations 37

    Business requirements Functional design Technical design REST/HTTP Coding Consistent code Rich generated code Shared libraries API, µ-services: principles and patterns applied Strong interactions with business stakeholders Object Oriented Design requirements Automatic / guided design APIs editors paths: /customers: get: summary: "" description: "" operationId: "getCustomer" parameters: - in: "body" name: "customer" description: "" required: true schema: $ref: "#/definitions/Customer" responses: 201: description: "" schema: type: "integer" format: "int32" Manual design low consistency ‘Simple’ code Low consistency Methods in enterprises X ‘Simple’ code Low consistency paths: /customers: get: summary: "" description: "" operationId: "getCustomer" parameters: - in: "body" name: "customer" description: "" required: true schema: $ref: "#/definitions/Customer" responses: 201: description: "" schema: type: "integer" format: "int32" Manual design low consistency Low interactions with business stakeholders requirements
  22. Avro schema Designer: from model to Java 38 Schema Avro

    Schema Avro Java Designing the specific message Many different schemas from the same model Schema Avro Serializer Data Schema Avro Deserializer Data Data model