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.). La démarche de rationalisation d'hier se transforme en levier de création de valeur. Cette session reviendra sur les enjeux business et techniques de la culture API. Nous adresserons ensuite les points clés d’une stratégie API, de la conception au management d’API.

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

6. 6

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 2013Juillet 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 : HTTPPile 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 BrowserWeb 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 xxxRecherche
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/HTTPXML/HTTP
AD
Jersey / SpringSOLr
Apache
ApacheJSON / 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
LEGACYIS
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
LEGACYIS
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/

45. 45

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
DELETEDELETE 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

74. 74

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 !