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

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 fboutzakhti@octo.com Frédéric Schäfer Consultant Senior OCTO Suisse fschafer@octo.com Jérôme Van Der Linden Consultant Senior OCTO Suisse jvanderlinden@octo.com
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
7. 7 Pourquoi une architecture cible WOA
8. 8 Internet-Of-Things is the next big thing! source : www.objetconnecte.com/de-plus-en-plus-de-choses-connectees/
9. 9 AnyTime, AnyWhere, AnyDevice
10. 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
11. 11 GUI Jetable Septembre 2013 Juillet 2008
12. 12 GUI Jetable source : lci.tf1.fr
13. 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
14. 14 Définition Application Programming Interface Façade par laquelle un logiciel offre des services à d’autres logiciels
15. 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
16. 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
17. 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
18. 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 « « » »
19. 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
20. 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
21. 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
22. 22 Démarche « web service » Démarche API Contractualisation avec le client Usages ouverts WS vs API Données orchestrées Données brutes ?
23. 23 Open API
24. 24 Evolution des APIs
25. 25 Statistiques d’utilisation des APIs twitter.com vs api.twitter.com
26. 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!
27. 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).
28. 28 Quelles APIs ? source : megabee.com/ Quoi exposer ? Quels niveaux d’API ? Quelques exemples
29. 29 Le facteur temps
30. 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
31. 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  
32. 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
33. 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
34. 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  
35. 35 Level 2 « APIs semi-publiques » – Cas Multi-Devices : Le Kiosk Back-end API Multi-Devices
36. 36 Level 2 « APIs semi-publiques » – Cas Partenaire : SNCF SI SNCF API Partenaires
37. 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
38. 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 »
39. 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
40. 40 api3.geo.admin.ch Level 3 « APIs publiques » : OpenData / OpenAPI Source : http://okfn/opendata
41. 41 Ouvrir son SI Quelle est votre cible API ? source : alivecampus.com/
42. 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
43. 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 »
44. 44 Designer vos (Web) APIs (REST) RESTFUL vs Pragmatisme Conception REST Pagination, filtre, versioning, … source : www.tuvie.com/
46. 46 RESTFUL martinfowler.com/articles/richardsonMaturityModel.html Pragmatique RESTFUL
47. 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/
48. 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
49. 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
50. 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
51. 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
52. 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
53. 53 Tester son API
54. 54 ÉTAPE 3 Publier et évangéliser API : Une méthode de conception en 3 étapes API Management
55. 55 Manager vos APIs Services de management Solutions de management Organisation source : www.apivet.eu
56. 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  
57. 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  
58. 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
59. 59 Portail Admin
60. 60 Portail Admin
61. 61 Statistiques
62. 62 Portail Développeur
63. 63 Business Application API SaaS provider Connecteur
64. 64 Proxy Monitoring Security API PROXY Business Application API
65. 65 Business Application Service Proxy Monitoring Security API GATEWAY Application Application Service Service API Gateway Médiation Routage Cache
66. 66 Solutions d’API Management
67. 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
68. 68 Conclusion source : www.public-domain-image.com
69. 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.
70. 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
71. 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
72. 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
73. 73 Pour aller plus loin source : www.remedioscaseros.eu
75. 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  
76. 76 Fintech Day Jeudi 26 Novembre – Genève Conférence – Table ronde – Présentations Fintech Coming soon…
77. 77 Questions source : www.sciencesetavenir.fr
78. 78 Merci !