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
Slide 5
Slide 5 text
5
De nouveaux défis
ATAWAD
Des IHM éphémères
Une évolution technologique
Un monde de plus en plus ouvert
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
7
Pourquoi une architecture cible WOA
Slide 8
Slide 8 text
8
Internet-Of-Things is the next big thing!
source : www.objetconnecte.com/de-plus-en-plus-de-choses-connectees/
Slide 9
Slide 9 text
9
AnyTime, AnyWhere, AnyDevice
Slide 10
Slide 10 text
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
Slide 11
Slide 11 text
11
GUI Jetable
Septembre 2013
Juillet 2008
Slide 12
Slide 12 text
12
GUI Jetable
source : lci.tf1.fr
Slide 13
Slide 13 text
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
Slide 14
Slide 14 text
14
Définition
Application
Programming
Interface
Façade par laquelle
un logiciel
offre des services
à d’autres logiciels
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
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
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
«
«
»
»
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
22
Démarche « web service » Démarche API
Contractualisation
avec le client
Usages ouverts
WS vs API
Données orchestrées
Données
brutes
?
Slide 23
Slide 23 text
23
Open API
Slide 24
Slide 24 text
24
Evolution des APIs
Slide 25
Slide 25 text
25
Statistiques d’utilisation des APIs
twitter.com vs api.twitter.com
Slide 26
Slide 26 text
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!
Slide 27
Slide 27 text
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).
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
Slide 31
Slide 31 text
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
Slide 32
Slide 32 text
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
Slide 33
Slide 33 text
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
Slide 34
Slide 34 text
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
Slide 35
Slide 35 text
35
Level 2 « APIs semi-publiques » – Cas Multi-Devices : Le Kiosk
Back-end
API Multi-Devices
Slide 36
Slide 36 text
36
Level 2 « APIs semi-publiques » – Cas Partenaire : SNCF
SI SNCF
API Partenaires
Slide 37
Slide 37 text
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
Slide 38
Slide 38 text
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 »
Slide 39
Slide 39 text
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
41
Ouvrir son SI
Quelle est votre cible API ?
source : alivecampus.com/
Slide 42
Slide 42 text
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
Slide 43
Slide 43 text
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 »
Slide 44
Slide 44 text
44
Designer vos (Web) APIs (REST)
RESTFUL vs Pragmatisme
Conception REST
Pagination, filtre, versioning, …
source : www.tuvie.com/
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/
Slide 48
Slide 48 text
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
Slide 49
Slide 49 text
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
Slide 50
Slide 50 text
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
Slide 51
Slide 51 text
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
Slide 52
Slide 52 text
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
Slide 53
Slide 53 text
53
Tester son API
Slide 54
Slide 54 text
54
ÉTAPE 3 Publier et évangéliser
API : Une méthode de conception en 3 étapes
API Management
Slide 55
Slide 55 text
55
Manager vos APIs
Services de management
Solutions de management
Organisation
source : www.apivet.eu
Slide 56
Slide 56 text
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
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
Slide 59
Slide 59 text
59
Portail Admin
Slide 60
Slide 60 text
60
Portail Admin
Slide 61
Slide 61 text
61
Statistiques
Slide 62
Slide 62 text
62
Portail Développeur
Slide 63
Slide 63 text
63
Business
Application
API
SaaS provider
Connecteur
Slide 64
Slide 64 text
64
Proxy
Monitoring
Security
API PROXY
Business
Application
API
Slide 65
Slide 65 text
65
Business
Application
Service
Proxy
Monitoring
Security
API GATEWAY
Application
Application
Service
Service
API
Gateway
Médiation
Routage
Cache
Slide 66
Slide 66 text
66
Solutions d’API Management
Slide 67
Slide 67 text
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
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.
Slide 70
Slide 70 text
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
Slide 71
Slide 71 text
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
Slide 72
Slide 72 text
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
Slide 73
Slide 73 text
73
Pour aller plus loin
source : www.remedioscaseros.eu
Slide 74
Slide 74 text
74
Slide 75
Slide 75 text
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
Slide 76
Slide 76 text
76
Fintech Day
Jeudi 26 Novembre – Genève
Conférence – Table ronde – Présentations Fintech
Coming soon…