La parole est aux speakers : Alexandre Daubois
Jusqu’au mois de mai 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
JsonPath: Pour des API IncassablesSi vous demandez aux devs PHP s'ils ont déjà créé ou utilisé des API renvoyant des données au format JSON, c'est un euphémisme de dire que la majorité répondra par l'affirmative. Dans cet océan (voire univers !) d'API utilisant le format JSON pour communiquer, il peut parfois être difficile de garantir la robustesse des réponses que nous envoyons en tant que créateurs de ces API. C'est là que JSON Path entre en jeu. Après 4 ans de développement, une spécification officielle décrivant un « langage de requête pour JSON » a été publiée en février 2024. Symfony vous permet d'utiliser ce langage grâce au nouveau composant JsonPath de la version 7.3, qui fournit toute une série d'outils pour booster vos tests d'intégration et vérifier avec précision les retours de vos API JSON. Symfony va encore plus loin en 7.4 pour vous permettre d'étendre cette nouvelle syntaxe, avec comme toujours, un DX examplaire. Vous ne pourrez bientôt plus jamais casser votre API en production ! |
C.P.E. 22/05/2026 15:30-15:50 |
Est ce que JSONPath change la manière dont on conçoit ses API ou seulement la manière dont on les teste ?
Ce n’est pas la première chose à laquelle j’ai pensé, mais cette question me fait me rendre compte que oui, ça pourrait avoir un impact sur la façon de concevoir les APIs.
Je ne pense pas que la différence soit très profonde et qu’une nouvelle ère est devant nous.
Mais si on fait le parallèle avec les tests unitaires plus classiques, on a toujours le même constat : tu veux tester une méthode immense, qui fait le thé et le café ? Bon courage, et c’est parfois juste impossible. J’ai envie de croire que les personnes qui feront usage de JsonPath pourront avoir ce même déclic. « Mon test sur cet endpoint est interminable, j’ai 100 assertions et c’est super dur à maintenir sans chemin JSON Path alambiqué ? Peut-être que je devrais séparer les choses pour avoir des endpoints avec une seul responsabilité ». Le principe de responsabilité unique, on en revient toujours à ça !
Pour aller un peu plus loin, j’ai vu des usages de JsonPath au-delà des tests que j’ai trouvé super intéressants. Typiquement, une interface qui permet de lire une réponse JSON d’un fournisseur tiers et d’extraire une donnée (la réponse d’un LLM par une API, à tout hasard !). Chaque implémentation définit le bon JsonPath selon le fournisseur requêté pour récupérer le champ précis qui contient le réponse (ils définissent chacun leur format de réponse évidemment), et on a une super abstraction. Je n’y avais jamais pensé, et j’ai trouvé ça génial comme utilisation. C’est vraiment smart.
Quelles bonnes pratiques recommandes-tu pour l’utiliser efficacement dans un projet Symfony ?
Pas forcément de bonnes pratiques particulières. Ça ressemble un peu à du test par regex si on veut, mais avec une syntaxe qui me semble plus lisible au premier coup d’œil. Mais ça peut quand même être un peu velu par moment, alors un commentaire (ou mieux, un message d’échec d’assertion personnalisé !) expliquant ce que le chemin JSON cherche peut être une bonne idée.
C’est un composant qui est encore un peu jeune et les devs ont encore le temps de se l’approprier. Il y a fort à parier que l’exemple que j’ai donné dans la réponse précédente soit juste le début des cas auxquels je n’ai pas pensé.
Une intégration encore plus forte dans Symfony est prévue, mais d’ici là, profitez du fait que le composant soit super léger et avec (quasi) aucune dépendance pour expérimenter avec. C’est un des plus « simple » que propose Symfony, et cependant bel et bien RFC compliant.
Côté prérequis, deux petits polyfills, et JsonStreamer optionnel pour une recherche optimisée dans vos JSON volumineux et une gestion encore meilleure de la mémoire. L’outil est petit, mais il a de la réserve !
Tu es le créateur de JSON Path, pour quelles raisons as-tu décidé de créer ce composant ?
Comme beaucoup, j’ai fait mes premiers tests d’API JSON avec Behat, et notamment les « Mink Context » il y a plusieurs années. Une bibliothèque permettait notamment de tester très facilement la sortie JSON des endpoints, mais le projet a été abandonné sans remplacement. Depuis, j’ai toujours trouvé que les tests d’endpoints en JSON était un peu laborieuse. Puis, un jour, je suis tombé un peu par hasard sur la RFC 9535 décrivant JsonPath. C’est récent, ses premières ébauches remontent à 2020 et la sortie officielle de la RFC est février 2024.
Bref, je trouvais ça très intéressant, et une bibliothèque permettant l’utilisation de JsonPath en PHP existait déjà, mais c’était une implémentation assez sommaire. Pas du tout « RFC compliant » en tout cas. Un bon début, mais ce n’était pas mis à jour depuis des années. J’ai directement vu le potentiel de cette syntaxe, et c’est assez naturellement que j’ai voulu proposer la meilleure intégration possible pour PHP. Pour moi, la suite logique a été de le proposer comme composant Symfony.
Tout ça pour dire : aucun outil n’existait pour faire ça en PHP et c’était bien dommage. Alors autant se lancer et le proposer au plus grand nombre avec le soutien de Symfony !
Une conférence présentée par
|
Alexandre DAUBOIS |
Alexandre est CTO chez Les-Tilleuls.coop et une personnalité influente dans l'écosystème PHP. Acteur majeur dans le monde de l'open source, il est membre actif des core team de Symfony et FrankenPHP. Il est aussi core maintainer de l'interpréteur PHP. Son expertise dans la création de code robuste et de haute qualité est condensée dans son livre « Clean Code in PHP ». Conférencier international lors d'événements tels que SymfonyLive et ForumPHP, Alexandre partage ses connaissances approfondies sur des sujets allant de la cybersécurité à la théorie de la programmation orientée objet, tous liés par un fil conducteur : la conception de logiciels faciles à maintenir pour les décennies à venir. |