Sorties API Platform

API Platform 4.3 est sorti le 13 mars 2026. L’ajout principal est le support MCP : vos ressources API peuvent maintenant être exposées comme outils et ressources pour des agents LLM sans infrastructure supplémentaire. À côté de ça, deux améliorations pratiques sortent du lot : Scalar comme UI de documentation alternative, et les vérifications de sécurité qui s’exécutent avant que le state provider soit appelé. Support du serveur MCP Le Model Context Protocol est le standard émergent pour connecter des LLMs à des outils et sources de données externes. 4.3 embarque une intégration MCP expérimentale qui se mappe directement sur le modèle de ressources d’API Platform. ...

API Platform 4.2 est arrivé en septembre 2025. Trois changements se distinguent : un JSON streamer pour les grandes collections qui évite de bufferiser toute la réponse en mémoire, un ObjectMapper qui remplace le câblage manuel dans les flux DTO basés sur stateOptions, et l’autoconfiguration de #[ApiResource] sans enregistrement de service explicite. JSON streamer pour les grandes collections Le serializer Symfony par défaut construit la réponse complète en mémoire avant de l’écrire dans la sortie. Pour une collection de 10 000 éléments, cela signifie allouer un tableau PHP, le sérialiser en string, et garder les deux en mémoire jusqu’au flush de la réponse. À grande échelle, c’est la source des erreurs OOM qui forcent à ajouter de la pagination partout. ...

API Platform 4.1 est arrivé en février 2025 avec un lot de fonctionnalités moins axées sur de nouvelles capacités que sur la mise en production des existantes. La validation stricte des paramètres de requête gagne une propriété de première classe. OpenAPI gagne un mécanisme pour découper les grandes APIs en specs séparées. GraphQL obtient les contrôles de prévention des abus qui lui manquaient. Validation stricte des paramètres de requête La 3.3 avait introduit la validation des paramètres de requête en opt-in. La 3.4 avait déprécié le comportement permissif. La 4.1 la formalise avec une propriété native strictQueryParameterValidation sur les ressources et opérations : quand elle est à true, les paramètres de requête inconnus renvoient 400. ...

API Platform 4.0 est sorti neuf jours après la 3.4, fin septembre 2024. Le numéro de version est honnête : il n’y a pas de nouvelle architecture, et la migration depuis la 3.4 est courte si on a résolu les dépréciations. Ce qui en fait un majeur, c’est le changement de scope — API Platform n’est plus un framework uniquement Symfony — et un défaut d’opinion qui inverse six ans de comportement PUT. ...

API Platform 3.4 est arrivé en septembre 2024 comme dernier mineur avant le saut vers la 4.0. La fonctionnalité principale est le BackedEnum comme ressource complète — pas juste un champ typé, mais un enum qui est lui-même un endpoint API. BackedEnum comme ressources API Depuis PHP 8.1, les classes BackedEnum ont un ensemble fixe de cas avec des valeurs de support string ou integer. API Platform 3.4 permet de mettre #[ApiResource] directement sur un BackedEnum : ...

API Platform 3.3 est sorti en avril 2024 avec un ensemble d’ajouts ciblés. Aucun d’eux ne remodèle l’architecture — la 3.2 avait déjà clos ce chapitre. Ce que la 3.3 apporte, c’est du contrôle sur des choses qui étaient soit codées en dur soit nécessitaient un contournement : les headers de réponse, la visibilité des liens sur les sous-ressources, et les webhooks dans la spec générée. Configuration déclarative des headers Avant la 3.3, définir des headers de réponse personnalisés nécessitait soit un processor personnalisé qui modifiait l’objet réponse, soit un event listener Symfony sur kernel.response. Les deux approches fonctionnaient mais vivaient en dehors de la définition de la ressource. ...

API Platform 3.2 est arrivé en octobre 2023 avec trois changements qui ont fait avancer le modèle d’état : les erreurs sont devenues des ressources, les sous-ressources sont revenues sous une forme qui s’intègre vraiment dans l’architecture, et le dernier point d’extension hérité — les event listeners — a été formellement remplacé. Les erreurs comme ressources Avant la 3.2, la gestion des erreurs était en dehors du modèle de ressources. Les exceptions étaient interceptées par un event listener Symfony et converties en réponse, avec un contrôle limité sur la forme de la sortie. ...

Quatre mois après la 3.0, API Platform 3.1 est arrivé avec le premier lot de fonctionnalités construites sur le nouveau modèle d’état. Tous les changements ne sont pas spectaculaires, mais l’un d’eux résout un problème qui a engendré beaucoup de contournements alambiqués en 2.x : votre ressource API n’a plus besoin d’être votre entité Doctrine. La séparation ressource/entité En 2.x, API Platform fonctionnait mieux quand votre ressource API et votre modèle de persistance étaient la même classe. Utiliser un DTO comme surface API était possible via le système Input/Output DTO, mais ce système a été supprimé en 3.0 — il compliquait le modèle d’état sans apporter suffisamment de bénéfices. ...

API Platform 3.0 est arrivé en septembre 2022 avec Symfony 6.1 comme prérequis strict et une architecture de base qui ne ressemblait en rien à la 2.x. Le guide de migration est long. La raison pour laquelle il est long est intéressante. L’ancien modèle avait une fuite conceptuelle. DataProviderInterface et DataPersisterInterface étaient appelés pour chaque requête HTTP, mais le provider recevait le contexte de l’opération comme un indice — pas comme un contrat. Un provider de collection et un provider d’item étaient des interfaces distinctes, mais les deux vivaient dans le même seau mental : “choses qui retournent des données.” La couche HTTP savait ce qui était demandé ; le provider devait reconstruire cette connaissance à partir d’indices passés dans le tableau $context. ...