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

Démystifions L'API Culture

Jérôme Van Der Linden
September 30, 2015
34

Démystifions L'API Culture

En cette ère digitale, les usages changent : les IHM sont multiples, accessibles n’importe où et n’importe quand, mais surtout de plus en plus éphémères. Nos systèmes d’informations doivent évoluer afin de gérer cette accélération.

Si la volonté de rendre le SI modulaire n’est pas nouvelle (architectures orientées services, technologies associées, etc.), de nouvelles cultures et pratiques nous sont insufflées par les Géants du Web pour y parvenir (API First, OpenAPI, etc.).

Jérôme Van Der Linden

September 30, 2015
Tweet

Transcript

  1. 1 Tél : +41 21 312 94 15 www.octo.com ©

    OCTO 2015 Avenue du théâtre 7 CH-1005 Lausanne - SUISSE Démystifions l’API-culture ! source : wall.alphacoders.com
  2. 2 Tél : +41 21 312 94 15 www.octo.com ©

    OCTO 2015 Avenue du théâtre 7 CH-1005 Lausanne - SUISSE Farhdine Boutzakhti Consultant Senior OCTO Suisse [email protected] Frédéric Schäfer Consultant Senior OCTO Suisse [email protected] Jérôme Van Der Linden Consultant Senior OCTO Suisse [email protected]
  3. 3 Tél : +41 21 312 94 15 www.octo.com ©

    OCTO 2015 Avenue du théâtre 7 CH-1005 Lausanne - SUISSE Démystifions la culture API !
  4. 4 Agenda De nouveaux défis Quelles APIs ? Designer vos

    (Web) APIs Manager vos APIs •  ATAWAD •  Des IHM éphémères •  Une évolution technologique •  Un monde de plus en plus ouvert •  Quoi exposer ? •  Quels niveaux d’API ? •  Quelques exemples •  Architecture •  Sécurité •  Solutions de management •  Organisation •  REST •  Pragmatisme vs RESTFUL •  Conception •  Pagination, filtres, versioning… 1 2 3 4
  5. 5 De nouveaux défis ATAWAD Des IHM éphémères Une évolution

    technologique Un monde de plus en plus ouvert
  6. 6

  7. 10 Desktop/native applications Web services, data etc. Application server User

    interface MV* engine Request (HTTP, RMI, Corba) data Web 1.0 application User interface Web browser MV* engine Web services, data etc. Application server 1990 HTTP request HTML + CSS JSP MV* Web application in the browser 2012 Application server Web services, data etc. Web browser User interface MV* engine HTTP request JSON data Web application with AJAX 2006 Application server Web services, data etc. Web browser User interface AJAX engine MV* engine HTTP request UI fragment UI Evolution des GUI
  8. 13 Un SI à 2 vitesses VS Un back-end plus

    lourd à faire évoluer Rationalisation Maitrise des coûts Des interfaces de plus en plus nombreuses, sophistiquées et éphémères   Besoins métiers   Innovation   Concurrence source : www.flickr.com/photos/88394234@N04/8139271342
  9. 15 Les APIs : une charnière GUI multiples et éphémères

    Stockage distribué Services modulaires et scalables Les APIs sont au cœur des architectures de demain
  10. 16 Service Oriented Architecture (SOAP API based) SOA (2000) Couche

    de services SOAP Mutualisation et rationalisation Transactionnel, ACID, sécurisé fakecompany App. server Web Browser App. server HTTP request HTML CSS JS Images … Models Controllers Business Delegate Web application #1 SOA Business Layer Views Centralized Business Logic accessible over the network getProducts() addProductToCart(1) updateStock() validCustomerPayment() completeOrder() … App. server Web Browser HTTP request HTML CSS JS Images … Models Controllers Business Delegate Web application #2 Views DATA Database
  11. 17 Pile SOAP… XML SOAP WSDL WS-Policy WS- Reliability WS-

    Security WS-Context WS- Eventing WS-Trust ... ... ... HTTP Pile lourde : WS-*/WSDL/SOAP… sur HTTP
  12. 18 SOAP critiqué WS-* style Web Services are "Web" in

    name only […] WS-* violates (or at best ignores) the architectural principles of the Web. Nick Gall VP Gartner Group Paul Downey Chief Web Services Architect The SOAP "stack" is a mess, and currently only the simplest of services are able to interoperate. stackoverflow.com/questions/76595/soap-or-rest-for-web-services « « » »
  13. 19 Service Oriented Architecture (SOAP API based) SOA (2000) Couche

    de services SOAP Mutualisation et rationalisation Transactionnel, ACID, sécurisé Appels de serveur à serveur Contrat « fort » Complexe Peu interopérable Pas adapté aux devices et au web moderne fakecompany App. server Web Browser App. server HTTP request HTML CSS JS Images … Models Controllers Business Delegate Web application #1 SOA Business Layer Views App. server Web Browser HTTP request HTML CSS JS Images … Models Controllers Business Delegate Web application #2 Views DATA Database
  14. 20 Back to basics XML SOAP WSDL WS-Policy WS- Reliability

    WS- Security WS-Context WS- Eventing WS-Trust ... ... ... HTTP HTTP Texte, JSON, XML, etc. Pile légère : HTTP Pile lourde : WS-*/WSDL/SOAP… sur HTTP
  15. 21 Web Oriented Architecture (REST API based) Architecture légère Basée

    sur le protocole HTTP Consommable par les clients modernes … ATAWAD App. server https://api.fakecompany.com/v1/{resources} Web Browser Web Browser HTTP request (REST) HTTP status (+Json +HATEOAS links) Models Controllers REST API Views Centralized Business Logic accessible over the network HTTP as the universal applicative protocol GET /products PATCH /carts {product:1} PATCH /stocks POST /payments PATCH /orders … HTTP request (REST) HTTP status (+Json +HATEOAS links) Models Controllers Views DATA Database Web application #1 Web application #2 Business Business Business Logic fakecompany
  16. 22 Démarche « web service » Démarche API Contractualisation avec

    le client Usages ouverts WS vs API Données orchestrées Données brutes ?
  17. 26 API First : s’ouvrir vers l’extérieur dès le commencement

    Memo de Jeff Bezos (2002) 1) All teams will expose their data and functionality through service interfaces. […] 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6) Anyone who doesn’t do this will be fired. 7) Thank you; have a nice day!
  18. 27 En synthèse Des interfaces de plus en plus nombreuses,

    sophistiquées et éphémères. L’ouverture est devenue un enjeu de premier ordre, pour innover, pour tisser un écosystème. La mouvance SOAP/XML n’a pas su répondre à ces enjeux. Les basiques HTTP reviennent en force. L’ouverture ne se résume pas aux services, ne présume pas de l’usage. Les Géants du Web ont montré le chemin (openAPI, API First).
  19. 28 Quelles APIs ? source : megabee.com/ Quoi exposer ?

    Quels niveaux d’API ? Quelques exemples
  20. 30 Des données, mais également des services associés API Données

    « froides » Données «vivantes» Services Ex : Horaires « théoriques » Tous les jours à 8h24, TGV Lausanne <-> Paris Ex : Horaires « Temps Réel » : Le TGV 9264 partira avec 4 min de retard. Ex : Itinéraires Pour aller de Chailly à Paris, prendre le bus 7, puis le M2, puis le TGV 9264
  21. 31 Ouvrir son SI Objec&fs   Désiloter    Ra&onaliser  sur

     les   ressources  et  services  du   cœur  de  mé0er    Adopter  les  standards  et   la  performance  des   architectures  du  WEB   Les  enjeux     API  Design     API  Architecture   En interne Level 1 « APIs privées » À des partenaires ou des terminaux Level 2 « APIs semi publiques » Au monde entier Level 3 « APIs publiques » Objec&fs    Proposer  à  des   partenaires  de   consommer  les  APIs  pour   développer  son  business      Répondre  à  la  profusion   de  terminaux  émergents  :   réponse  à  la  digitalisa0on   Les  enjeux    Sécurisa0on     Accoun0ng  :  logs    Documenta0on  publique    API  management   Objec&fs    Faire  émerger  de  nouveaux   usages    Recruter  des  u0lisateurs   pour  rendre  un  service   incontournable    Se  reconcentrer  sur  son   cœur  de  mé0er    Créer  un  écosystème  que   l’on  rachète   Les  enjeux    API  Management    Aspects  Communautaires  :   Doc,  Events  
  22. 32 Level 1 « APIs privées » : Cas 1

    Proxy Front Services API (ESB Light) Nouveaux services Services xxx Recherche Front End (MV*) Partenaires (MV*) - Agrégation - Transformation - Routage - Décorélation des cycles - Authentification (SSO) - Authorisations Services (Bloc applicatifs) Front End Internes et consommateurs de l'API HTML5/CSS* Angular JSON / HTTP XML/HTTP XML/HTTP AD Jersey / Spring SOLr Apache Apache JSON / HTTP JSON / HTTP
  23. 33 Level 1 « APIs privées » : Cas 2

    Channels Multichannel services Analytics Steering Identity management and federation Persistency (Omnichannel Memory) API Instrumentation of channels Social Networks External data (Internet / open data) Customer, partners & offers 360 vision LEGACY IS API Collection API Consolidated monitoring Recom mendati on Pre- scoring Developers Partners Real time engagement engine Case & process management choreography secure Data lake Partners Open API LEGACY IS OPEN API Customer Interactions Collection Data refinery IVR Compliance
  24. 34 Ouvrir son SI Objec&fs   Désiloter    Ra&onaliser  sur

     les   ressources  et  services  du   cœur  de  mé0er    Adopter  les  standards  et   la  performance  des   architectures  du  WEB   Les  enjeux     API  Design     API  Architecture   En interne Level 1 « APIs privées » À des partenaires ou des terminaux Level 2 « APIs semi-publiques » Au monde entier Level 3 « APIs publiques » Objec&fs    Proposer  à  des   partenaires  de   consommer  les  APIs  pour   développer  leur  business      Répondre  à  la  profusion   de  terminaux  émergents  :   réponse  à  la  digitalisa0on   Les  enjeux    Sécurisa0on     Accoun0ng  :  logs    Documenta0on  publique    API  management   Objec&fs    Faire  émerger  de  nouveaux   usages    Recruter  des  u0lisateurs   pour  rendre  un  service   incontournable    Se  reconcentrer  sur  son   cœur  de  mé0er    Créer  un  écosystème  que   l’on  rachète   Les  enjeux    API  Management    Aspects  Communautaires  :   Doc,  Events  
  25. 35 Level 2 « APIs semi-publiques » – Cas Multi-Devices

    : Le Kiosk Back-end API Multi-Devices
  26. 37 Level 2 « APIs semi-publiques » – Cas Partenaire

    / Ouvert QuickBooks Online (QBO) API Donne un accès online à la base QuickBooks – outil de comptabilité pour PMEs
  27. 38 Ouvrir son SI Objec&fs   Désiloter    Ra&onaliser  sur

     les   ressources  et  services  du   cœur  de  mé0er    Adopter  les  standards  et   la  performance  des   architectures  du  WEB   Les  enjeux     API  Design     API  Architecture   Objec&fs    Proposer  à  des   partenaires  de   consommer  les  APIs  pour   développer  son  business      Répondre  à  la  profusion   de  terminaux  émergents  :   réponse  à  la  digitalisa0on   Les  enjeux    Sécurisa0on     Accoun0ng  :  logs    Documenta0on  publique    API  management   Objec&fs    Faire  émerger  de  nouveaux   usages    Recruter  des  u0lisateurs   pour  rendre  un  service   incontournable    Se  reconcentrer  sur  son   cœur  de  mé0er    Créer  un  écosystème  que   l’on  rachète   Les  enjeux    API  Management    Aspects  communautaires  :   doc,  events   En interne Level 1 « APIs privées » À des partenaires ou des terminaux Level 2 « APIs semi publiques » Au monde entier Level 3 « APIs publiques »
  28. 39 Level 3 « APIs publiques » : Cas AXA

    Banque Open API Exemples : l’API AXA Banque Axa Banque API   Open API publique   Accès aux données bancaires des clients   Comptes, cartes, soldes, transactions   Historique de ~ 10 ans   URL : https://api.axabanque.fr/   API ouverte de type 3
  29. 40 api3.geo.admin.ch Level 3 « APIs publiques » : OpenData

    / OpenAPI Source : http://okfn/opendata
  30. 42 Dois-je développer des APIs ? Si vous ne le

    faites pas, quelqu’un le fera pour vous ! Sans que vous en ayez le contrôle. Photo sous licence CC Zigazou
  31. 43 En synthèse Objec&fs   Désiloter    Ra&onaliser  sur  les

      ressources  et  services  du   cœur  de  mé0er    Adopter  les  standards  et   la  performance  des   architectures  du  WEB   Les  enjeux     API  Design     API  Architecture   Objec&fs    Proposer  à  des   partenaires  de   consommer  les  APIs  pour   développer  son  business      Répondre  à  la  profusion   de  terminaux  émergents  :   réponse  à  la  digitalisa0on   Les  enjeux    Sécurisa0on     Accoun0ng  :  logs    Documenta0on  publique    API  management   Objec&fs    Faire  émerger  de  nouveaux   usages    Recruter  des  u0lisateurs   pour  rendre  un  service   incontournable    Se  reconcentrer  sur  son   cœur  de  mé0er    Créer  un  écosystème  que   l’on  rachète   Les  enjeux    API  Management    Aspects  Communautaires  :   Doc,  Events   En interne Level 1 « APIs privées » À des partenaires ou des terminaux Level 2 « APIs semi publiques » Au monde entier Level 3 « APIs publiques »
  32. 44 Designer vos (Web) APIs (REST) RESTFUL vs Pragmatisme Conception

    REST Pagination, filtre, versioning, … source : www.tuvie.com/
  33. 45

  34. 47 API : Une méthode de conception en 3 étapes

    ÉTAPE 1 Identifier les ressources et leur hiérarchie ÉTAPE 2 Designer et implémenter l’API ÉTAPE 3 Publier et évangéliser source : www.tuvie.com/
  35. 48 Identifier les ressources et leur hiérarchie Stores (France) PublicationTypes

    (Revues) Categories (Mode) Publications (Elle) Issues (no 328) Articles Stores PublicationTypes Categories Publications Issues Articles publicationtypes (list) categories (list) publications (list) issues (list) articles (list) lastissue similars (list) subcaterories (list) mostread (list) ÉTAPE 1 Identifier les ressources et leur hiérarchie
  36. 49 Designer et implementer son API – 1/3 Choix du

    verbe HTTP Choix du MediaType Définition des liens nécessaires (HATEOAS) par rapport au diagramme … ÉTAPE 2 Designer et implémenter l’API
  37. 50 En pratique, la version d’une API est fondamentale pour

    le consommateur de l’API :   1er niveau de l’URL Designer et implementer son API – 2/3 On utilise des noms concrets pour décrire les ressources de l’API   Les termes utilisés doivent être usuels et concrets : Customers, orders, addresses, products,…   Et non tirés d’un « jargon fonctionnel » https://api.fakecompany.com/v1/issues/124 1 HTTP comme protocole applicatif   Utiliser les verbes standards   Utiliser HTTPS 2 On utilise les STATUS CODES HTTP comme codes retours   On utilise les STATUS CODES HTTP comme codes d’erreurs 3 Utilisation des entêtes HTTP pour préciser la requête   Ex : négociation du contenu avec l’entête « Accept » 5 4 https://api.fakecompany.com/issues/124 Accept: application/xml; application/json < 200 OK https://api.fakecompany.com/issues/124 < Content-Type: application/xml; charset=UTF-8 DELETE DELETE S
  38. 51 Designer et implementer son API – 3/3 Pagination  

    Devrait être gérée sur toutes les ressources de l’API GET https://api.fakecompany.com/v1/issues? range=60-72 6 Filtre   Limitation du nombre de ressources récupérées lors d’un appel en spécifiant des valeurs attendues 7 Tri   Ordonnancement des résultats de requête d’une collection : sort / desc 8 Mots réservés   First, last, count, … 10 Réponses partielles   Limiter les champs (et la taille du flux) 9 &adult=false&new=true &sort=name&desc=issuenumber &fields=name,issuenumber,description
  39. 52 Documenter son API Mécanismes transverses Sécurité, filtres, code d’erreur,

    pagination, entêtes,… Ressources URL, description, paramètres, données retournées,… Documentation API
  40. 54 ÉTAPE 3 Publier et évangéliser API : Une méthode

    de conception en 3 étapes API Management
  41. 56 Build vs Buy L’API  est  le  point  d’entrée  unique

     vers  le  SI   Fonc0onnalité  cri0que  et   «  différenciante  »   Clé́  de  réussite  déterminante  pour  votre   mé0er       Gateway  /  Portails     La  publica&on  de  services,  avec   versioning   L’annuaire  et  la  documenta&on  des   services   Les  sta&s&ques  d’usage   Portail  développeurs  (internes  et   externes)   Quotas,  QoS,  montée  en  charge   Sécurité   Sécurisa0on  standardisée  (OAuth2)   Ges0on  de  la  sécurité  (WAF,  DOS,   DDOS…)   Ges0on  des  comptes  et  contrôle  d’accès   API     1   GATEWAY  /  PORTAIL  /  SECURITE    2  
  42. 57 Services de l’API Management          

                     Back-­‐office   API                          Applica0ons   API  Management             +   Portails     à  Portail  API  (Admin)   à  Monitoring   à  Habilita0on     à  Versions   à  Sta0s0ques   à  Portail  Développeur     à  Documenta0on   à  Annuaire   à  Self-­‐enrollment   à  FAQ,  Forum,  blog   Proxy     à  Sécurité   à  Logging   à  Métriques   Gateway     à  Transforma0ons   à  Routage   à  Cache  
  43. 58 Sécurité Sécurisation de la couche transport : HTTPS  

    Confidentialité / Intégrité / Authentification Identifier l’application appelante   Utilisation d’une clé unique   Application id ou équivalent (client_id oauth2) Identifier l’utilisateur et sécuriser ses ressources   OAUTH2   Autorisation d’accès entre 2 ou 3 parties   Très utilisé par les Géants du Web (notamment Google) OpenID Connect   Surcouche à OAUTH2
  44. 65 Business Application Service Proxy Monitoring Security API GATEWAY Application

    Application Service Service API Gateway Médiation Routage Cache
  45. 67 Développeurs tiers * * ou internes si API privée

      Développe des services et applications avec les APIs   Découvre et s’approprie les APIs via le portail développeurs   Suit ses statistiques d’utilisation des APIs   Demande des clés APIs IT puis Marketing* * D’abord un projet technique, l’API devient ensuite un projet métier Rôles et profils autour de l’API Communication IT – Production IT – Études   Conçoit et développe les APIs   Rédige la documentation technique   Mesure et améliore la performance des APIs   Administre les environnements   Gère la Scalabilité   Gère les SLA et la disponibilité   Gère la sécurité   Anime la communauté des développeurs   Est présent sur les réseaux sociaux   Évangélise et forme les développeurs   Administre le portail développeurs API Product Manager Développeur & Tech Lead Ops Community Manager Développeur d’application   Rôle de « Product Owner »   Coordonne les développements avec les autres équipes   Garant du succès des APIs   Définit et suit les indicateurs
  46. 69 Conclusion De nouveaux défis 1 Des interfaces de plus

    en plus nombreuses, sophistiquées et éphémères. L’ouverture est devenue un enjeu de premier ordre, pour innover, pour tisser un écosystème. SOAP/XML n’a pas su répondre à ces enjeux, HTTP / REST reviennent en force. L’ouverture ne se résume pas aux services, ne présume pas de l’usage.
  47. 70 Conclusion De nouveaux défis 1 Des APIs pour vos

    données, froides ou vivantes, et pour vos services. 3 niveaux d’API pour …   « Désiloter », rationnaliser et standardiser votre SI.   Ouvrir votre SI à vos clients, à leurs terminaux et à vos partenaires.   Ouvrir votre SI à des développeurs externes, créer un écosystème et faire émerger de nouveaux usages. Faites-le avant que d’autres ne le fassent pour vous. Quelles APIs ? 2
  48. 71 Conclusion De nouveaux défis Quelles APIs ? 1 2

    Identifiez les ressources et leur hiérarchie. Designez et implémenter votre API. RESTFul est un graal, privilégiez une approche pragmatique.   Utilisez le protocole HTTP : verbes, codes de retour, entêtes,…   La « Quick Reference Card » OCTO est là pour vous aider.   Testez et documentez. Publiez et évangélisez. Designer vos (Web) APIs 3
  49. 72 Conclusion De nouveaux défis Quelles APIs ? Designer vos

    (Web) APIs 1 2 3 Concentrez vos efforts de développement sur le cœur de l’API, votre métier, votre différenciant. Basez-vous sur une solution du marché pour l’API Management (sécurisation, publication, monitoring,…).   Nous avons un penchant pour les « pure players ». L’animation de communauté et le marketing sont une des clés du succès. Manager vos APIs 4
  50. 74

  51. 75 Pour aller plus loin http://www.octo.academy/fr/f/39-api-ouvrir-son-si-developper-son-modele-d-affaire -­‐  Appréhender  les  enjeux

     techniques,  fonc&onnels  et  mé&er  des  APIs   -­‐  Savoir  évaluer  les  plateformes  d’API  management  adaptées  aux  besoins  des  mé&ers   -­‐  Déployer  et  maintenir  une  stratégie  d’API  
  52. 76 Fintech Day Jeudi 26 Novembre – Genève Conférence –

    Table ronde – Présentations Fintech Coming soon…