Télécharger pour lire hors ligne
![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 ?](https://image.slidesharecdn.com/api-210912142947/85/Comprendre-utiliser-et-creer-une-API-24-320.jpg)
Comprendre, utiliser et créer une API
- 1.
- 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’UNEAPI • 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.
- 6. POURQUOI ? • “Ichoose 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’adapteraux é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 • Industrialisationet 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 desystème d’exploitation API de langage de programmation API d’infrastructure API ou service web
- 12. SPÉCIFICITÉS DES APIPOUR 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 EXPLOSIONDU 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 ResourceLocator 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 RECEVOIRUNE 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ÉPONSESREÇ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 → Ona 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.
- 29. Google et sesservices APIs proposées par Google Mais également Google Cloud APIs
- 30. OPEN RATP • Comprendrela documentation et analyser les services offerts Open Data RATP
- 31. NOTRE API ANOUS DE JOUER
- 32. AVANT TOUT… Conseilset 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 POURLES CURIEUX!
- 34. LEXICOGRAPHIE • API :ApplicationProgramming 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 plusloin… • 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.