Utilisation de l'API

Une fois notre API en place, nous souhaitons la consommer depuis l'application de news.

Lorsqu'un utilisateur souhaite s'enregistrer à la newsletter, nous voulons contacter l'API afin de valider l'enregistrement de l'email.

HTTP Client

Pour effectuer des requêtes avec Symfony, on peut utiliser le composant http-client.

Client/Serveur

Bien que notre application de news soit une application Symfony et soit un serveur du point de vue d'un navigateur, elle devient ici un client de notre API : elle souhaite consommer un service externe

Dans le contrôleur, nous allons pouvoir type-hinter l'interface HttpClientInterface. Nous aurons alors une instance sur laquelle nous pourrons appeler la méthode request :

$response = $client->request(
  Request::METHOD_POST, // On utilise la méthode POST
  "http://localhost:8001/api/check", // l'URL que nous souhaitons requêter
  [
    // La donnée sera automatiquement convertie au format JSON et intégrée au corps de la requête
    'json' => ['email' => $newsletterEmail->getEmail()]
  ]
);

La $response, elle, est une instance de classe implémentant l'interface ResponseInterface.

Sur cette instance, on peut alors appeler la méthode toArray() pour automatiquement extraire le contenu de la réponse sous forme de tableau :

$data = $response->toArray();
$isSpam = $data['result'] === 'spam';

Nous pouvons alors décider quoi faire en fonction de la situation : si l'email est un spam, alors nous pouvons, par exemple, ajouter une erreur spéciale au formulaire, pour l'invalider :

$form->addError(new FormError("Une erreur est survenue lors de la vérification de l'email"));

ScopingHttpClient

Dans le code produit jusque-là, il reste un gros problème : l'URL de notre API est inscrite en dur dans le code.

Nous voudrions un peu plus de flexibilité, surtout concernant les environnements. En local, pendant le développement, notre API est peut-être lancée sur localhost:8001, mais en production, qu'en sera-t-il ? L'URL sera certainement différente.

Il s'agit alors d'une différence au niveau des environnements. Nous pouvons donc configurer le client pour qu'il s'appuie sur une variable d'environnement, plutôt que de laisser l'URL en dur dans l'application.

Nous pouvons configurer cela au niveau du framework, en déclarant un scoped_clients :

config/packages/framework.yaml

framework:
  # ...

  http_client:
    scoped_clients:
      spam.checker:
        base_uri: "%env(SPAM_CHECKER_BASE_URI)%"

Indentation

Attention à l'indentation avec les fichiers YAML

Dans notre fichier .env.local, nous renseignons la variable d'environnement correspondante :

.env.local

SPAM_CHECKER_BASE_URI=http://localhost:8001

Après cette configuration, Symfony nous crée un service autowiré automatiquement, que nous pouvons type-hinter de la façon suivante :

public function newsletterSubscribe(
  //...
  HttpClientInterface $spamChecker
): Response {
  //...
  $response = $spamChecker->request(
    Request::METHOD_POST,
    "/api/check",
    [
      'json' => ['email' => $newsletterEmail->getEmail()]
    ]
  );
}

Type et nom

Ici, le type-hint est également complété par le nom du paramètre : Symfony a créé ce service et l'a relié automatiquement à notre scoped client. C'est comme si nous lui disions que nous voulons précisément le HttpClient Spam Checker. Il sait de quelle configuration il s'agit

À présent, nous pouvons utiliser /api/check uniquement. Symfony préfixera automatiquement l'URI avec l'adresse renseignée dans la variable d'environnement.