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

Creating the new: adidas APIs

Cb2527e0c321fc1eb6753c06f45da93c?s=47 Z
October 11, 2017

Creating the new: adidas APIs

The talk was given by Oldrich Novak and Zdenek Z Nemec at Nordic APIs, Stockholm. October 11th, 2017.

Cb2527e0c321fc1eb6753c06f45da93c?s=128

Z

October 11, 2017
Tweet

Transcript

  1. https://youtu.be/kyum6GZp3r4

  2. CREATING  THE NEW ADIDAS APIS ZDENEK “Z” NEMEC OLDRICH NOVAK https://goodapi.co

    @zdne GOOD API oldrich.novak@adidas-group.com
  3. SPORTS COMPANY

  4. TECH COMPANY

  5. PAST‐ADIDAS APIS

  6. LACK OF VISIBILITY AND GOVERNANCE

  7. LACK OF CONSISTENCY AND QUALITY

  8. LACK OF OWNERSHIP

  9. LACK OF BUSINESS FOCUS API DESIGN FOLLOWING TECHNOLOGY NOT BUSINESS NEEDS

  10. COMPLEX PROCESSES EXPOSING FUNCTIONALITY FOR CLIENTS

  11. THE PROMISED LAND

  12. REUSE OF EXISTING FUNCTIONALITY SINGLE SOURCE OF TRUTH COLLABORATION VISIBILITY

    Visibility
  13. CONSISTENT DEVELOPER EXPERIENCE WHILE CONSUMING APIS SUPERB EXPERIENCE Client DX

  14. SPEEDY DESIGN, DEVELOPMENT, TESTING AND PUBLISHING THROUGH STANDARDIZED AND HIGHL Y‐ AUTOMATED PROCESSES

    FAST DELIVERY Fast Delivery Server DX
  15. PERFORMANCE, STABILITY & EXTENSIBILITY Performance Stability & Extensibility

  16. SECURITY Security

  17. CLEAR OWNERSHIP Ownership

  18. HOW DID  WE GET THERE HOW DID  WE GET THERE

  19. PEOPLE TOOLS PROCESSES

  20. TRAINED EXPERTS STANDARDIZED TOOLS AUTOMATED PROCESSES

  21. PEOPLE ORGANIZATION CHANGES, TRAININGS & THE ROLE OF THE API

    EVANGELIST
  22. ADIDAS API LIFECYCLE

  23. ADIDAS API LIFECYCLE 1 DESIGN DEVELOP & TEST DEPLOY PUBLISH CON

    SUM E AN ALYZE 2 3 4 5 6 7 UPDATE Prototype Feedback
  24. 1 DESIGN DEVELOP DEPLOY PUBLISH CON SUM E AN ALYZE

    2 3 4 5 6 7 UPDATE DESIGN API Visibility Client DX Stability & Extensibility
  25. API FIRST API IS PRODUCT

  26. DESIGN-FIRST API DESCRIPTION IS CONTRACT

  27. “The API description is the source of truth, NOT the

    API implementation.”
  28. SINGLE REPOSITORY FOR CONTRACTS Visibility

  29. DESIGN & IMPLEMENTATION MATURITY Client DX

  30. WEB API DESIGN MATURITY MODEL http://amundsen.com/talks/2016-11-apistrat-wadm/2016-11-apistrat-wadm.pdf Source:

  31. RESOURCE-CENTRIC DESIGN AT MINIMUM Web API Design Maturity Model Level

    2
  32. AFFORDANCE-CENTRIC DESIGN IDEALL Y Web API Design Maturity Model Level

    3
  33. RICHARDSON MATURITY MODEL https://martinfowler.com/articles/richardsonMaturityModel.html Source:

  34. HTTP PROTOCOL SEMANTICS AT MINIMUM Richardson Maturity Model Level 2

  35. HYPERMEDIA CONTROLS IDEALL Y Richardson Maturity Model Level 3 Stability &

    Extensibility
  36. HYPERMEDIA SOLVES MANY DESIGN PATTERNS RELATIONS, COLLECTIONS, PAGINATIONS, EMBEDDING, VERSIONING AND BEYOND-CRUD

    OPERATIONS Stability & Extensibility
  37. HAL HYPERTEXT‐APPLICATION LANGUAGE

  38. HAL RMM Level 2 RMM Level 3

  39. DESIGN GUIDELINES Fast Delivery Client DX Security Stability & Extensibility

  40. DESIGN-TIME GOVERNANCE

  41. ADIDAS API GUIDELINES https://www.gitbook.com/book/adidas-group/api-guidelines/

  42. ADIDAS API GUIDELINES Protocol-level Message-level Application-level Functional Requirements Governance Non-Functional Requirements

    Governance Execution Evolution Security Usability Maintainability Scaleability Extensibility https://www.gitbook.com/book/adidas-group/api-guidelines/
  43. OPEN-SOURCED ON GITHUB Visibility https://github.com/adidas-group/api-guidelines

  44. DESIGN CONSISTENCY Client DX Fast Delivery HOW TO MAKE EVERYBODY

    FOLLOWS THE GUIDELINES
  45. AUTOMATED DESIGN CHECKS USING APIARY  STYLE GUIDE

  46. AUTOMATIC DESIGN GOVERNANCE

  47. 1 DESIGN DEVELOP DEPLOY PUBLISH CON SUM E AN ALYZE

    2 3 4 5 6 7 UPDATE DEVELOP & TEST‐API
  48. BOILERPLATES, TEMPLATES & GUIDELINES Fast Delivery Server DX

  49. SPRINGBOOT MICROSERVICE MAVEN ARCHETYPE

  50. CONTRACT VERIFICATION Fast Delivery Server DX

  51. DREDD — HTTP‐API TESTING FRAMEWORK

  52. CONTRACT VERIFICATION Dredd CLI API Description API Implementation Endpoint 1

    Endpoint 2 Endpoint 3 Endpoint 4
  53. JENKINS DREDD PLUGIN

  54. JENKINS DREDD+APIARY PLUGIN

  55. AUTOMATED SECURITY CHECK Security Work in Progress SECURITY‐AT THE SOURCE

  56. Performance Fast Delivery Server DX 1 DESIGN DEVELOP DEPLOY PUBLISH

    CON SUM E AN ALYZE 2 3 4 5 6 7 UPDATE DEPLOY API
  57. None
  58. Security Ownership 1 DESIGN DEVELOP DEPLOY PUBLISH CON SUM E

    AN ALYZE 2 3 4 5 6 7 UPDATE PUBLISH API
  59. EXPOSE API USING MASHERY

  60. ARCHITECTURE

  61. ADIDAS API MANAGEMENT  GUIDELINES NAMING CONVENTIONS, PACKAGING, THROTTLING, AUTHENTICATION AND KEY

    POLICES
  62. MASHERY TOOLBELT Fast Delivery AUTOMATED API MANAGEMENT PROVISIONING USING THE API DESCRIPTION.

    FOLLOWING API MANAGEMENT  GUIDELINES
  63. MASHERY TOOLBELT https://www.npmjs.com/package/mashery-toolbelt Work in Progress https://github.com/adidas-group/mashery-toolbelt

  64. Client DX Stability & Extensibility 1 DESIGN DEVELOP DEPLOY PUBLISH

    CON SUM E AN ALYZE 2 3 4 5 6 7 UPDATE CONSUME API
  65. API DOCUMENTATION INTERACTIVE, CODE SAMPLES & DEBUGGING PROXY Client DX

  66. DEVELOPER PORTAL APPLICATION KEYS PROVISIONING, GETTING STARTED & USAGE PRINCIPLES

    Work in Progress Client DX
  67. DEVELOPERS PORTAL Work in Progress

  68. LOOSE COUPLING CLIENT MUST FOLLOW ROBUSTNESS PRINCIPLE, AND ACT INDEPENDENTL Y,

    NOT‐ASSUMING ANY INTERNAL IMPLEMENTATION OF THE SERVICE Client DX Stability & Extensibility
  69. Visibility 1 DESIGN DEVELOP DEPLOY PUBLISH CON SUM E AN

    ALYZE 2 3 4 5 6 7 UPDATE ANALYZE API
  70. ANALYZE

  71. AUTOMATED API AVAILABILITY TESTING  WITH RUNSCOPE

  72. Stability & Extensibility Client DX 1 DESIGN DEVELOP DEPLOY PUBLISH

    CON SUM E AN ALYZE 2 3 4 5 6 7 UPDATE UPDATE API
  73. CHANGES & VERSIONING

  74. –Mark Nottingham “The fundamental principle is that you can’t break

    existing clients, because you don’t know what they implement, and you don’t control them. In doing so, you need to turn a backwards-incompatible change into a compatible one.”
  75. NO URI VERSIONING https://blog.goodapi.co/ https://blog.apisyouwonthate.com/

  76. RULES FOR EXTENDING • You MUST NOT take anything away

    (related: Minimal Surface Principle , Robustness Principle) • You MUST NOT change processing rules • You MUST NOT make optional things required • Anything you add MUST be optional (related Robustness Principle)
  77. CHANGE MANAGEMENT • Resource identifier including any query parameters and

    their semantics • Resource metadata • Action the resource affords • Relation with other resources • Representation format ANY‐CHANGE TO IS SUBJECT TO RULES FOR EXTENDING
  78. BACKWARD INCOMPATIBLE CHANGES IMPLIES NEW RESOURCE VARIANT /greeting?first=John&last=Appleseed /named-greeting?first=John&last=Appleseed first

    and last are optional but first needs to be made required
  79. ADIDAS API LIFECYCLE 1 DESIGN DEVELOP & TEST DEPLOY PUBLISH CON

    SUM E AN ALYZE 2 3 4 5 6 7 UPDATE Prototype Feedback
  80. FULL PICTURE

  81. AUTOMATED CONTRACT-DRIVEN API LIFECYCLE

  82. Bitbucket Apiary Jenkins Mashery API Gateway Mashery Cloud K8s Platfrom

    API Consumer Apiary Documentation Apiary Mock Service API Description API Description Service Implementation Apiary Style Guide Dredd Plug-in Apiary Test Reporter Apiary adidas team APIs Apiary Documentation Apiary Mock Service Analytics Admin Mashery Toolbelt 2 3 4 5 6 7 1 1 Design 2 Develop 3 Deploy 4 Publish 5 Use 6 Analyze 7 Update Security Checks Runscope Kibana
  83. http://goodapi.co/api-lifecycle

  84. THE FUTURE: REDESIGN B2B BUSINESS & ENABLE DIGITAL  CREATION THROUGH

    APIS
  85. COMPLETE B2B HAPPENING  THROUGH APIS

  86. DIGITAL  CREATION: CREATING  THE NEW

  87. THANK YOU ZDENEK “Z” NEMEC OLDRICH NOVAK https://goodapi.co @zdne GOOD

    API oldrich.novak@adidas-group.com
  88. Q&A ZDENEK “Z” NEMEC OLDRICH NOVAK https://goodapi.co @zdne GOOD API

    oldrich.novak@adidas-group.com
  89. https://www.karliekloss.com