5 - API custom avec ApiPlatform

ApiPlatform repose sur deux principes clés pour la gestion de son flux de données:

• Les providers

• Les processors

Provider:

Un Provider est responsable de lire et de fournir des données à l’API.

• C’est lui qui va aller chercher les ressources (dans une base de données, un service externe, un fichier…).

• Par défaut, API Platform utilise un DoctrineOrmProvider pour récupérer les entités depuis la base.

• Mais on peut créer note propre Provider pour :

  • Appeler une API externe.

  • Charger un fichier CSV/JSON.

  • Mixer plusieurs sources de données.

En résumé : le Provider = "lecture" des données.

Processor:

Un Processor est responsable de modifier les données.

• Il gère la création, la mise à jour et la suppression.

• Par défaut, API Platform utilise un DoctrineOrmProcessor qui enregistre/efface l’entité via Doctrine.

• Mais on peut créer note propre Processor pour :

  • Envoyer les données à une API externe au lieu de les stocker en DB.

  • Appliquer une logique métier avant la sauvegarde.

  • Déclencher des événements (ex : envoi d’email après création).

En résumé : le Processor = "écriture / traitement" des données.

Exemple d'un processor custom

Pour la création de notre utilisateur, nous avons besoin d'une logique custom. On ne souhaite pas simplement le sauvegarder en BDD, mais on doit aussi hasher son mot de passe avant la sauvegarde.

Pour simplifier notre workflow, nous allons créer une ressource pour ce point d'API plutôt que d'utiliser notre entité.

Une ressource est tout simplement un objet qu'on expose via notre API.

• Ça peut être une entité Doctrine (ex. User, Product, Article)

• Ou une classe PHP qui n’est pas liée à une base de données (ex. un DTO, une réponse d’API externe).

En gros, c’est ce que l'API met à disposition du monde extérieur. Par convention, si ce n'est pas une entité, apiPlatform la range dans src/ApiResource

Créons donc notre première resource:

<?php declare(strict_types=1);

namespace App\ApiResource;

use ApiPlatform\Metadata\Post;
use App\State\UserCreationProcessor;

#[Post(processor: UserCreationProcessor::class)]
class UserCreation
{
    public string $email;
    public string $password;
}

Sur cette resource, j'ai juste mis email + password, avec l'action POST qui point sur un processor custom.

Il est possible de créer un state processor avec le maker de Symfony: bin/console make:state-processor

On va pouvoir venir modifier ce processor pour qu'il s'adapte à la resource visé

<?php declare(strict_types=1);

namespace App\State;

use ApiPlatform\Metadata\Operation;
use ApiPlatform\State\ProcessorInterface;
use App\ApiResource\UserCreation;
use App\Entity\User;

/**
 * @implements ProcessorInterface<UserCreation, User>
 */
class UserCreationProcessor implements ProcessorInterface
{
    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): User
    {
        $user = new User();
        $user->email = $data->email;

        // hash password, save in DB...

        return $user;
    }
}

Et voilà comment créer très simplement un processor custom. L'idée est globalement la même pour les providers mais dans l'autre sens !

Voir aussi: Code HTTP: Pas un hasard