Mathieu Desnouveaux

API

20 sketchnotes disponibles pour ce thème

🔗

Conception et développement d'APIs

← Retour aux sketchnotes
Sketchnote illustrant les filtres API Platform présentée lors d'un meetup AFUP Lorraine. Le schéma explique qu'un filtre permet de limiter des ressources selon des critères par des attributs sur nos entités (ORM/ODM & Elastic Search). Il y a une refonte suite à l'arrivée de la compatibilité avec Laravel. Le découpage d'un filtre fourre-tout (SearchFilter avec IRI Filter, Exact Filter, Partial Filter, OR Filter, etc.) devient plus simple et respectueux. Les filtres plus simples montrent l'usage d'objets > tableaux pour la maintenance du framework et la possibilité de créer ses filtres personnalisés avec un Query Builder. Le Parameter Provider permet de transformer un paramètre (URI + parent + chain + resource) et la documentation automatique. La génération par Maker ainsi que la migration sans BC break avec les commandes Maker & Rector pour migrer.

API Platform : repenser les filtres

Publié le 30 novembre 2025
Par Vincent Amstoutz
🐘 PHP 🔗 API 🏗️ Architecture
📅 AFUP Lorraine
Sketchnote illustrant la communication entre utilisateur et agent IA présentée lors d'un meetup AFUP Lorraine. Le schéma explique l'architecture API Multi Platform avec IA (FastAPI, Laravel) connectée via un MCP. Le flux commence par une APP (mail, trad, météo, domotique) qui communique avec une API (Fast API streaming pour l'IA), puis un agent IA (Mistral Small 3.5 en local, Ollama) et enfin le MCP (protocole agent-outil). Le processus se décompose en demande, transmission, analyse (avec un cerveau illustré), réponse (avec icône message), réponse (avec icône crayon pour écriture), et outils (clé à molette). L'architecture permet une communication fluide et structurée entre l'utilisateur et l'intelligence artificielle.

Communication entre utilisateur et agent IA

Publié le 11 décembre 2025
Par Nathanael Heitz
🔗 API 🤖 AI/ML
📅 AFUP Lorraine
Sketchnote sur la normalisation des erreurs d'API. Le concept central: erreur = comportement inattendu. L'objectif avec cible: expliquer pourquoi ça marche pas et quoi faire. Identification des problèmes, retry/mécanisme continu. Section 'Comment' détaille: Cataloguer (ce qui peut arriver dans mon système, ce qui peut arriver hors de mon système, ce qui est rare et que je gère pas), Formater (RFC 7807 vers RFC 9457). Dans API Platform l'erreur est un 'ornithorynque' - c'est un assemblage de concepts: exception, error, resource. L'idée ampoule: étendre l'assemblage pour notre domaine, ajouter des metadata pour l'automatisation. Un ornithorynque illustre le concept.

Rendez vos devs front heureux en normalisant toutes vos erreurs d'API

Publié le 29 novembre 2025
Par Clément Herreman
🔗 API 🐘 PHP
📅 API Platform Conference
Sketchnote sur l'impact des LLMs sur la conception d'APIs. Le schéma présente le concept d'AI Agent (model using tools in loop). Un dessin indique qu'un agent fonctionne de manière similaire à un humain envers une application à travers web, CLI, API. Un shéma rappel que les APIs sont pour les interactions entre les machines. Un fleche part de cette notion pour rappeler qu'un agent fonctionne comme un humain et à besoin d'aide. Une flèche explique que l'aide en question inclut un prompt, une réponse API pour décorer/customiser, les messages d'erreurs. Le schéma conclu avec le message central 'It's all about improving' qui met l'accent sur l'amélioration de la DX (Developer Experience) et de l'AX (Agent Experience) avec consistance, documentation (for code, for developers, for agents), et exemples. Une section Tokens explique compression de texte, petites optimisations avec impact, équation 'less tokens = less cost'.

How LLMs are changing the way we should build APIs

Publié le 29 novembre 2025
Par Fabien Potencier
🤖 AI/ML 🔗 API
📅 API Platform Conference
Sketchnote présentant les nouveautés d'API Platform 4.2. Les éléments clés incluent: Metadata (behind API resources, adding mutator), ApiFilter (4 types de fonctionnalités), Parameter (has type now, URI variable provider), JSON Schema Enhancement (PB23F OpenAPI validator), State Options (by Symfony Object Mapper), JSON Streamer, Laravel, FrankenPHP (worker node faster) et une flèche vers la version 5.0 avec l'arraigné, mascotte du framework.

How API Platform 4.2 is redefining API development

Publié le 29 novembre 2025
Par Antoine Bluchet
🔗 API 🐘 PHP
📅 API Platform Conference
Sketchnote présentant l'intégration de Redis avec API Platform. Le schéma illustre l'object mapping pour convertir des objets vers des formats partageables, Redis comme base de données clé-valeur (RAM vers performance, string vers JSON hash). Une balance compare les avantages (format objet proche, performance) et inconvénients (mapping à faire, sécurité des données, persistance). RedisOM est présenté comme solution avec attributs pour le mapping, persistence à la Doctrine, et requêtes via Redis Search.

API Platform × Redis

Publié le 29 novembre 2025
Par Clément Talleu
🔗 API 🚀 Performance 🛠️ Tools
📅 API Platform Conference
Sketchnote illustrant l'intégration de gRPC dans API Platform. Le schéma montre l'architecture avec FrankenPHP comme connecteur central entre un client, API Platform (écrit en PHP) et une API Go utilisant gRPC. Les avantages de gRPC sont mis en avant: format binaire, faible latence, typage fort et agnosticisme du langage. Les cas d'usage concernent les micro-services, l'IoT ou encore les projets demandant de la résilience.

Enhance your API Platform APIs with Go thanks to FrankenPHP

Publié le 29 novembre 2025
Par Kévin Dunglas
🔗 API 🚀 Performance 🐘 PHP
📅 API Platform Conference
La sketchnote de la conférence 'Meeting or Missing Target' est une illustration colorée qui explore la durabilité dans le secteur technologique. En haut au centre, le titre 'Meeting or Missing Target' est affiché, avec le sous-titre 'Data Center, Hardware, AI, and Sustainability'. Sous le titre, une flèche horizontale illustre le modèle linéaire de consommation : 'Take', 'Make', 'Consume', 'Dispose'. Au centre, trois blocs blancs distincts représentent trois idées principales : 1. 'Sustainable Consumption' : Cette section propose des conseils pour une consommation durable, avec des bulles et des flèches indiquant des actions telles que 'Think Globally', 'Don't focus on carbon assessment only', 'Consider other things', 'Reuse', 'Material/Social', et 'Circular Economy'. 2. 'How Too' : Ce bloc met en avant les éléments clés à travers des cercles orange et bleus, soulignant l'importance de 'Compare', 'Be Proactive', et 'Evaluate'. 3. 'To Make Informed Decisions' : Cette section insiste sur l'utilisation des 'Right Metrics' et l'augmentation de la collecte de données pour définir des cibles précises et développer des métriques utiles. En bas, une phrase finale rappelle la nécessité de métriques pour aborder la durabilité.

Meeting or missing target: Data center, hardware, AI and sustainability

Publié le 05 décembre 2024
Par Deborah Andrews
🔗 API 🌱 Ecology
📅 API Days Paris
La sketchnote de la conférence "7 Key Lessons on Building Great REST APIs" par Vedran Cindrić présente une vue d'ensemble des meilleures pratiques pour concevoir des API REST efficaces. En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "7 Key Lessons on Building Great REST APIs", est écrit en lettres orange et noires sur fond blanc. La sketchnote est organisée autour de sept blocs principaux, chacun représentant une leçon clé relié par une ligne pointillée : 1. Design : Ce bloc met en avant l'importance de la sémantique, des méthodes HTTP spécifiques, des codes de réponse clairs, et de la versioning précoce. 2. Sécurité : Ce bloc souligne l'utilisation de HTTPS, l'authentification rigoureuse, la validation des données, et la protection des données. 3. Performance : Ce bloc recommande la mise en cache, la pagination, et l'optimisation des performances de la base de données. 4. Documentation : Ce bloc conseille une documentation descriptive avec des exemples et l'utilisation de standards comme OpenAPI. 5. Adoption : Ce bloc propose de fournir un SDK, un support technique, et un portail développeur de qualité pour faciliter l'intégration. 6. Gouvernance : Ce bloc recommande de définir des standards, centraliser la versioning, et établir un processus de revue des API. 7. Monétisation : Ce bloc conseille de proposer un niveau gratuit, un support commercial, et des tarifs prévisibles pour monétiser les API. Chaque bloc est entouré d'un cadre rouge et contient des notes manuscrites détaillant les points clés de chaque leçon.

7 Key Lessons on Building Great REST APIs

Publié le 04 décembre 2024
Par Vedran Cindrić
🔗 API 🏗️ Architecture
📅 API Days Paris
La sketchnote de la conférence de Gregor Hohpe présente les idées clés pour créer des abstractions efficaces. En haut, le titre "API Days Paris 2024" est affiché, suivi du titre de la conférence "Build Abstractions, Not Illusions". La sketchnote est organisée autour de plusieurs points : Limites Technologiques : La technologie doit être poussée à ses limites, tout en respectant ses contraintes. Plateformes et Complexité : Construire une plateforme lorsque quelque chose devient complexe pour augmenter la réutilisation et la collaboration. Pyramide IT : La construction de la base est coûteuse, et une planification excessive peut nuire à l'innovation. Plateforme Partagée : Une plateforme partagée offre une base standardisée pour l'innovation. Abstraction vs Illusion : Créer des abstractions claires et nommer les choses par leurs usages pour éviter les illusions. En bas, une note rappelle l'importance d'être explicite.

Build Abstractions, Not Illusions

Publié le 04 décembre 2024
Par Gregor Hohpe
🔗 API 🏗️ Architecture
📅 API Days Paris
La sketchnote de la conférence de Beppe Catanese présente sept règles pour créer des bibliothèques API conviviales pour les développeurs. En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "7 Rules for Crafting Developer Friendly API Libraries", est écrit en lettres orange et noires sur fond blanc. La sketchnote est structurée autour de plusieurs blocs et annotations : 1. Pourquoi (Why) : * Atteindre les développeurs qui vont exploiter les API. * Mettre en place des abstractions. * Augmenter la productivité. 2. Règles : * Open API Driven : Passer du schéma au code pour éviter la duplication. * Idiomatic : Adopter les conventions de langage et les frameworks. * Release Note : Déclarer les changements importants. * Code Snippets : Fournir de bons exemples de code. * Reference Implementation : Offrir divers exemples complets de cas d'utilisation. * Deprecation Markers : Utiliser des marqueurs pour indiquer l'obsolescence. * Great Documentation : Prioriser les meilleures pratiques de documentation. Des flèches et des annotations relient ces concepts pour montrer les relations entre les différentes règles.

7 Rules for Crafting Developer Friendly API Libraries

Publié le 03 décembre 2024
Par Beppe Catanese
🔗 API 🏗️ Architecture
📅 API Days Paris
La sketchnote de la conférence de Maxim Danilov présente une perspective alternative sur la documentation des spécifications OpenAPI (OAS). En haut à gauche, le titre "API Days Paris 2024" est affiché en lettres blanches sur fond rouge. Le titre de la conférence, "An Alternative View on Open API Docs: Start Finally Doing It Right", est écrit en lettres orange et noires sur fond blanc. La sketchnote est structurée autour de plusieurs blocs et annotations : 1. Un bloc "Problèmes" avec les point suivant : - Les spécifications OpenAPI ne décrivent pas comment organiser ou découvrir la documentation. - La documentation est difficile à comprendre pour les humains et les ordinateurs. - Les tests de grandes spécifications OAS consomment beaucoup de ressources. - Plusieurs standards similaires existent en même temps. 2. Un bloc "Solutions Proposées" avec les points suivant : - Diviser et conquérir : Diviser la documentation en fichiers plus petits pour une meilleure lisibilité et une consommation réduite de ressources. - Utiliser la méthode option : Fournir de petits fichiers YAML. - Utiliser un service : Servir des fichiers YAML à partir de fichiers OAS plus grands. Des flèches relient ces concepts pour montrer les relations entre les problèmes et les solutions proposées.

An Alternative View on Open API Docs: Start Finally Doing It Right

Publié le 03 décembre 2024
Par Maxim Danilov
🔗 API 🛠️ Tools
📅 API Days Paris