Un contrat d’API documenté par construction
La documentation OpenAPI et l’interface de test sont produites à partir du code. Le contrat publié reste aligné avec ce que l’API fait réellement, sans document à maintenir à la main.
Expertise · API Platform
Développeurs API Platform offshore : des API REST et GraphQL documentées et testées
Ressources, documentation OpenAPI, droits d’accès, filtres, cache et tests : nous livrons des API métier en production, faciles à consommer et à faire évoluer. Nos développeurs API Platform francophones, à Madagascar et à Maurice, encadrés par nos leads techniques, rejoignent votre équipe en régie, à distance, ou prennent en charge votre projet, en régie ou au forfait.
Visio de 30 minutes, gratuite et sans engagement, suivie d’un récapitulatif écrit avec un ordre de grandeur.
Les atouts pour votre produit
Pourquoi choisir API Platform ?
API Platform convient aux produits dont l’API est un livrable à part entière, avec un contrat lisible et documenté. Il s’appuie sur les composants de Symfony (sécurité, validation, sérialisation, cache HTTP) et sur Doctrine, ce qui le rend cohérent avec une application Symfony existante.
REST et GraphQL sur les mêmes ressources
Une même ressource peut être exposée en JSON-LD (Hydra), JSON:API, HAL ou GraphQL. Chaque consommateur choisit le format qui lui convient, sans dupliquer la logique côté serveur.
Les briques communes déjà en place
Pagination, filtres, tri, validation, gestion des erreurs et négociation de contenu sont fournis par le framework. L’équipe écrit moins de code répétitif et le comportement reste homogène d’une ressource à l’autre.
L’écosystème Symfony à disposition
Voters, Messenger, Doctrine, profilage et outils de test s’appliquent directement à l’API. Voir notre expertise développement Symfony.
Notre champ d’intervention
Ce que prennent en charge nos développeurs API Platform offshore.
Conception des ressources
Définir les ressources, leurs opérations et leurs représentations, sur des entités Doctrine ou des objets dédiés.
Sécurité & droits d’accès
Authentifier les clients, restreindre chaque opération et filtrer les données selon l’utilisateur.
Performance & temps réel
Limiter les requêtes, mettre en cache les réponses et pousser les mises à jour aux clients.
Tests & montées de version
Couvrir le contrat d’API par des tests automatisés et faire évoluer le framework sans casser les consommateurs.
Notre expertise API Platform
L’écosystème API Platform que nous maîtrisons.
Ressources & état
Attribut ApiResource, opérations explicites, State Providers et State Processors pour séparer la lecture et l’écriture des données de leur exposition. Objets dédiés (DTO) quand l’API ne doit pas refléter directement le schéma de base de données.
Données & Doctrine
Doctrine ORM et migrations, groupes de sérialisation, validation par contraintes Symfony, sur des bases relationnelles comme PostgreSQL ou MySQL.
Filtres & pagination
Filtres de recherche, de date, de tri et d’existence, filtres sur mesure, pagination par page ou par curseur, pagination partielle pour les gros volumes.
Sécurité
Expressions de sécurité par opération, voters Symfony, authentification par jetons (JWT, OAuth2), extensions Doctrine pour restreindre les collections aux données autorisées.
Cache & temps réel
Cache HTTP avec invalidation automatique des réponses, cache applicatif sur Redis, Mercure pour diffuser les modifications aux clients abonnés.
Admin & clients générés
API Platform Admin, basé sur React Admin, pour un back-office construit à partir de la documentation de l’API ; générateur de clients pour amorcer une interface Next.js, React ou Vue.
Sécurité, filtres et pagination
Des accès maîtrisés à chaque opération.
Une API expose les données plus directement qu’un écran. Nous définissons les règles d’accès opération par opération : qui peut lire une collection, modifier un élément, ou voir un champ précis. Les règles complexes sont portées par des voters testés, et les collections sont filtrées en base de données pour qu’un utilisateur ne reçoive que ce qu’il a le droit de voir.
Les filtres et la pagination font partie du contrat. Nous déclarons explicitement les paramètres acceptés, limitons la taille des pages et choisissons le mode de pagination selon le volume et l’usage : par page pour un back-office, par curseur pour une synchronisation ou un défilement continu.
Performance et temps réel
Une API rapide, qui informe ses clients.
Les lenteurs d’une API viennent souvent des requêtes générées : relations chargées une par une, sérialisation de graphes trop profonds, comptages coûteux sur de grandes tables. Nous profilons les opérations réelles avant d’optimiser, puis ajustons les groupes de sérialisation, les jointures et la pagination.
Le cache HTTP d’API Platform permet de servir les réponses depuis un proxy et de les invalider quand les données changent. Pour les écrans qui doivent se mettre à jour sans recharger, Mercure diffuse les modifications des ressources aux clients abonnés, en réservant les mises à jour privées aux clients autorisés.
Sur le terrain
De la technologie à un usage concret.
Pour une application métier qui sert à la fois un back-office, une application web et un partenaire, nous pouvons exposer un catalogue de ressources avec des droits différents selon le client appelant. Le back-office est généré à partir de la documentation, l’interface publique consomme la même API, et le partenaire reçoit un contrat OpenAPI versionné. Des tests vérifient chaque opération, les droits refusés comme les droits accordés.
Back-office et front-end
Une API pensée pour React et Next.js.
API Platform Admin construit une interface d’administration à partir de la documentation de l’API : listes, formulaires et filtres sont disponibles rapidement, puis personnalisés écran par écran. C’est une base efficace pour les équipes internes, à condition de garder les règles métier côté serveur.
Pour le front-end, la documentation OpenAPI permet de générer des types et des clients TypeScript, ce qui réduit les écarts entre l’API et l’interface. Nous développons ces interfaces en React ou en Next.js, avec le rendu serveur quand le référencement ou le temps d’affichage l’exigent.
Les choix qui comptent
Les choix à examiner avant de construire.
Exposer directement les entités Doctrine est rapide, mais lie le contrat d’API au schéma de la base. Pour une API publique ou destinée à durer, nous préférons souvent des objets dédiés et des State Providers, qui laissent le modèle de données évoluer sans casser les consommateurs. Le choix entre REST et GraphQL, la stratégie de versionnement et la politique de dépréciation se décident aussi au départ.
Pour une API existante, nous commençons par identifier les consommateurs, les opérations réellement utilisées et les écarts entre la documentation et le comportement. Un audit technique permet de prioriser ces sujets avant d’ajouter des fonctions.
Montées de version
Passer d’API Platform 3 à 4, puis préparer la suite.
API Platform 4 a retiré les fonctions dépréciées en 3.4 : la méthode recommandée consiste à passer d’abord en 3.4, traiter les avertissements de dépréciation, puis changer de version majeure. La version 4 demande PHP 8.2 au minimum et ne déclare plus l’opération PUT par défaut, ce qui peut modifier le contrat pour les clients qui l’utilisaient. La branche 5, désormais publiée, s’appuie sur Symfony 7.4 ou 8.
Nous préparons ces montées de version avec la mise à jour de Symfony et de Doctrine, en comparant la documentation OpenAPI avant et après pour détecter les changements visibles par les consommateurs. Pour le choix de la version de Symfony, voir notre article Symfony 7.4 ou 8.0 : comment choisir.
Du travail aux livrables
Une API que votre équipe peut reprendre.
Le périmètre de l’intervention précise les ressources à réaliser ou à reprendre, les consommateurs à servir et les conditions de validation. Nos leads techniques valident la conception et relisent le code livré ; nous préparons les éléments nécessaires pour comprendre les changements, les vérifier et poursuivre le travail.
- Contrat OpenAPI versionné
- Tests automatisés des opérations et des droits
- Procédures de déploiement et de montée de version
Comprendre la technologie
API Platform dans votre projet.
API Platform est un framework PHP open source dédié à la construction d’API. Historiquement construit sur Symfony, il prend aussi en charge Laravel depuis sa version 4. À partir de classes PHP décrites par des attributs, il expose des opérations REST et GraphQL, génère la documentation OpenAPI et gère la sérialisation, la validation, la pagination et les filtres.
Nous l’utilisons quand une application doit offrir une API stable à plusieurs consommateurs : une interface web, une application mobile, un partenaire ou un autre service du système d’information. Le framework prend en charge la mécanique commune à toutes les API ; le temps du projet va au modèle métier, aux règles d’accès et à la qualité du contrat.
Questions fréquentes
Vos questions.
Faut-il choisir entre API Platform et Symfony ?
Non. API Platform s’installe dans une application Symfony et en utilise les composants. Il remplace l’écriture manuelle des contrôleurs d’API, de la sérialisation et de la documentation, tandis que les services métier, la sécurité et les traitements asynchrones restent du code Symfony classique.
API Platform convient-il pour une API REST simple ?
Oui, si l’API doit être documentée, paginée, filtrée et sécurisée, ce qui est le cas de la plupart des API métier. Pour quelques points d’entrée très spécifiques sans ressources à exposer, des contrôleurs Symfony suffisent parfois ; nous en discutons au cadrage.
Peut-on proposer REST et GraphQL avec la même application ?
Oui. GraphQL s’active sur les ressources existantes et partage leurs règles de sécurité et de validation. Il faut toutefois limiter la profondeur et la complexité des requêtes pour éviter qu’un client ne déclenche des traitements trop coûteux.
Comment tester une API construite avec API Platform ?
Avec les outils de test fournis par API Platform, basés sur le client HTTP de Symfony, nous vérifions chaque opération, ses codes de réponse, ses droits d’accès et la conformité des réponses au schéma publié. Des jeux de données de test isolent chaque scénario, et les tests sont exécutés automatiquement à chaque changement.
Comment se passe une montée de version d’API Platform 3 à 4 ?
En deux temps : passage en 3.4 et correction des dépréciations, puis passage en version 4 avec les versions de PHP et de Symfony compatibles. Nous comparons le contrat OpenAPI avant et après, et prévenons les consommateurs des changements éventuels, comme le retrait de PUT des opérations par défaut.
Comment travailler avec vos développeurs API Platform : régie ou forfait ?
Le plus souvent en régie : nos développeurs API Platform rejoignent votre équipe à distance, dans une équipe dédiée encadrée par nos leads techniques, ou en renfort ciblé sur une compétence précise. Pour un projet long dont Etixio porte l’objectif et la conduite, le projet en régie est facturé au temps passé. Pour un périmètre court et stable, le projet au forfait fixe un prix, des livrables et une recette.
Parlons de votre API.
Présentez-nous l’API à construire ou à reprendre, ses consommateurs et les contraintes connues. Nous examinerons le contrat, les droits d’accès et le premier périmètre de travail avec votre équipe.