Support de cours de 3h donné à l'EPF Sceaux aux étudiants de la junior entreprise (mai 2018)

1. APPLICATION
PROGRAMMING
INTERFACES
COMPRENDRE, UTILISER
ET CRÉER

2. SOMMAIRE
• Carte d’identité d’une API
• Utilisation
• Consommateur
• Producteur
• Marché
• Catégories d’API
• Données véhiculées
• SOAP et REST
• Exemples
• Des idées qui émergent?
• Pour les curieux…

3. CARTE D’IDENTITÉ D’UNE API
• Quoi ? Ensemble de fonctions exposées par un programme tiers pour accéder à tout ou
partie de ses fonctionnalités
• Qui ? Par des développeurs pour des développeurs
• Comment ? N’importe quel langage de programmation !
• Une API ≡ plusieurs implémentations
• Par abus de langage, les API couramment utilisées et entendues comme telles sont des accès à des
web services
• Où et quand ? …

5. POURQUOI ?

6. POURQUOI ?
• “I choose a lazy person to do a hard job.
Because a lazy person will find an easy way to
do it.” ― Bill Gates

7. AVANT… MAINTENANT APRES?
???
S’adapter aux évolutions technologiques

8. Contrat tacite producteur-consommateur :
Qu’autorise-t-on à faire et comment ?

9. UTILISATION : CÔTÉ CONSOMMATEUR
PROS
• Utilisation de fonctionnalités même si expertise et/ou
ressources manquantes en interne
• Standardisation des API garantit des consensus
d’utilisation (ex. : standards HTTP, modèle REST, etc.)
→ grande communauté et possibilité d’entraide
• Mise en pratique rapide avant rachat ou recherche en
interne sur d’autres pistes
CONS
• Dépendance très forte au producteur → maintenance ±
accrue lors d’évolutions (modification des algorithmes,
dépréciation de fonctionnalités, voire cessation de
services)
• Problèmes de compatibilité entre API → boîte noire avec
les dépendances importées

10. UTILISATION :
CÔTÉ
PRODUCTEUR
• Industrialisation et monétisation des algorithmes et/ou des données
• Inclusion de nouveaux acteurs au sein de son marché (recrutement
des utilisateurs, intégration de nouveaux usages via feedbacks…)
• Maîtrise des données échangées : sécurisation des données plutôt que
d’un monolithe applicatif
• Pas de présupposé sur les technologies finales employées : support et
maintenance réduits aux fonctionnalités
• Implémentation respectueuse des standards (guidelines
préexistantes...) → Gain de temps lors des spécifications
• Découpage en micro-services : concentration sur cœur de
métier/fonctionnalité, même en interne

11. Catégories d’API
API de système d’exploitation API de langage de programmation
API d’infrastructure API ou service web

12. SPÉCIFICITÉS DES API POUR DEVICES « MOBILES »
• Prendre en compte les utilisateurs finaux! → ATAWAD
• Besoin d’instantané (AnyTime,AnyWhere)
• Multiplicité des interactions entre applications sur un ou entre appareil(s) (AnyDevice)
• Architecture client-serveur, les clients étant les appareils de X marques
• Optimisation des transmissions de données (requêtes, temps de traitement, etc.)
• Atomisation de l’information
• « Technology-agnostism »

13. MARCHÉ :
UNE EXPLOSION DU
TERME “API” EN
MARKETING
• Concentration sur un service fourni plutôt qu’un
produit – pas de dépendance matérielle!
• Réseaux facilement accessibles : mises à jour en temps
réel, possibilité de traitements asynchrones…
• Régulation des requêtes, meilleur management côté
serveur
• Business model ≡ licences et non produits
• Unités : nombre de données stockées, échangées,
nombre de requêtes effectuées, …

14. OPEN API != OPEN SOURCE !
Il existe une spécification sur ce que doit être une OpenAPI...
Une API incluant le mot « Open » permet de supposer
qu’elle respecte les contraintes de cette spécification.
+ Rarement un accès au code interne
+Très souvent limitées (restrictions via adresse IP, tokens, coût/nombre
par requêtes…)

15. DONNÉES
VÉHICULÉES
• Stateless : 2 états bien distincts, chacun géré par un côté
• État de l’application géré par le client
• État des ressources géré par le serveur
• Principes de la POO (Programmation Orientée-Objet)
• Communiquer via des objets
• Encapsulation des données
• Gestion de données : respecter les opérations CRUD
(Create, Read, Update, Delete)
• Sérialisation des données :

16. SOAP VERSUS REST
• Simple Object Access Protocol – Framework de protocoles
• Par Microsoft
• Verbeux, lisible et compréhensible par les « non-initiés » -- XML
• Nécessite de coder et maintenir des lecteurs et parseurs spécifiques → mise à jour client quand mise à
jour serveur
• REpresentational State Transfer – Style d’architecture
• Thèse de RoyThomas Fielding
• Ontologie et consensus sur l’écriture (verbes, statuts…)
• Les données peuvent changer rapidement → délégation d’une partie des fonctionnalités grâce à une
entente commune

17. POSER UNE QUESTION…
• Où se trouve la ressource ?
• Qu’est-ce qu’on va faire à cette ressource ?
• Qui je suis, pourquoi et comment je veux obtenir cette ressource ?
En quelle langue je parle, avec quel « alphabet » ?
• Des précisions sur ce qu’on va faire à la ressource
• URL
• Method
• Headers
• Body

18. URL
• Uniform Resource Locator
http:// sousdomaine.domaine.gigadomaine :8080 / dossier / sousdossier…
Protocole Chemin « absolu » sur le serveur
Port
Domaine et leurs divisions
UNE URL = UNE ressource (donnée, type de données, traitement…)
URLs = « endpoints »

19. MÉTHODES HTTP
• GET → Récupération d’une ressource
• PUT → Mise à jour/remplacement de ressources

20. MÉTHODES HTTP
• GET → Récupération d’une ressource
• PUT → Mise à jour/remplacement de ressources
• POST → Création d’une ressource
• DELETE → Suppression d’une ressource

21. MÉTHODES HTTP
• GET → Récupération d’une ressource
• PUT → Mise à jour/remplacement de ressources
• POST → Création d’une ressource
• DELETE → Suppression d’une ressource
• HEAD → Informations sur la ressource
• PATCH → Modifier une partie d’une ressource
• TRACE → Retourne ce qui a été reçu (debug)
• OPTIONS → Options de communication d’une ressource

22. … ET RECEVOIR UNE RÉPONSE
• Comment le serveur a réagi à la demande
• Dans quel langue, avec quels protocoles de communication la
ressource va être partagée
• Une mise en forme de ce qui a été demandé
• Status code
• Headers
• Body

23. ETATS DES RÉPONSES REÇUES (CODES HTTP)
• 1xx → Information
• 2xx → Requête réussie
• 3xx → Requête redirigée
• 4xx → Requête mal formulée (côté client)
• 5xx → Impossibilité de répondre à la requête (côté serveur)

24. HEADERS
Authorization → On a obtenu l’autorisation d’accéder aux ressources
Content-Type → Type du fichier demandé, et dans quel codage
Date → Quand est-ce que la requête a été faite ?
Expect → Qu’est-ce qu’on s’attend à avoir comme réponse ?
Host → Quel domaine (et sous-domaine…) a demandé la ressource ?
If-[condition] → Ce qu’on s’attend à avoir si certaines conditions
User-Agent → A partir de quel logiciel/navigateur essaie-t-on de récupérer la ressource ?

25. BODY
• Vide
• Texte « pur » (lisible sans traitement)
• Bits
• Fichiers multimédia
• Données ordonnées
• JSON
• XML
• HTML (directement interprété par le navigateur…)

26. MESURE DE QUALITÉ D’UNE API
• Expérience développeur : taille de la communauté, entraide, blogs, etc.
• Sécurité :
• Des données et traitements internes
• Des demandes des utilisateurs
• Bonne gestion des cas d’erreurs et codes HTTP pertinents
• Possibilité d’évolutions : features, données supplémentaires, optimisations…

27. EXEMPLES

29. Google et ses services
APIs proposées par Google
Mais également Google Cloud APIs

30. OPEN RATP
• Comprendre la documentation et analyser les services offerts
Open Data RATP

31. NOTRE API A NOUS DE JOUER

32. AVANT TOUT… Conseils et bonnes pratiques
• « Faites des dessins! »
• Penser à son public
• KISS (Keep It Simple, Stupid!)
• « Eating your own dog food »
• ATAWAD (AnyTime, AnyWhere, Any Device)
• Être pessimiste!
• « SISO » à éviter…

33. VOIR AUSSI POUR LES CURIEUX!

34. LEXICOGRAPHIE
• API :Application Programming Interface
• RPC : Remote Procedure Call
• SOAP : Simple Object Access Protocol
• WSDL :Web Service Document Language
• REST : REpresentational StateTransfer
• TTFAC :Time To First Api Call
• URL : Uniform Resource Locator

35. Pour aller plus loin…
• How to Create a REST Protocol
• Learn REST :A Tutorial
• SOAP vs REST differences
• Documenting APIs:A guide for technical writers
• Wikipedia forWebAPIs
• Public APIs for any use

36. NOTES ET
RÉFÉRENCES
• https://www.mediawiki.org/wiki/Web_APIs_hub