Retrouvez la version originale de cet article ici

Notre coopérative est fière de vous annoncer la sortie de la beta d’API Platform 2.4, enrichie d'un large éventail de nouvelles fonctionnalités ! Pour rappel, API Platform est un framework “full-stack” permettant de développer en un tour de main des projets basés sur des API. API Platform fournit :

Une bibliothèque d'API modulaire et complète, construite sur des composants de Symfony
Une interface d'administration générée dynamiquement à partir des spécifications de l'API, construite à l'aide de React et React Admin
Un générateur de client permettant d'échafauder des applications React / Redux, React Native et Vue.js à partir des spécifications de l'API

API Platform supporte les formats REST modernes (JSON-LD / Hydra, JSONAPI, OpenAPI, HAL…) ainsi que GraphQL. Pour créer votre projet, il vous suffit de décrire les structures publiques des données à exposer via l'API. API Platform se chargera d'exposer l'API Web et d’amorcer les clients pour qu'ils l'utilisent.

Les fonctionnalités apportées par la version 2.4 sont de haute volée. En voici la liste :

Le changelog complet est disponible sur GitHub. Découvrons maintenant ces nouvelles fonctionnalités !

Support de MongoDB

MongoDB est l’une des bases de données NoSQL les plus populaires. La prise en charge native de MongoDB était la fonctionnalité la plus demandée et la plus attendue d’API Platform ! Sam Van der Borght a commencé à se pencher sur ce sujet en mars 2016. En juillet 2017, la Pull Request a été transférée sur la V2 du framework par Pablo Godinez, avec l'aide de Hamza Amrouche (membre de la core team d'API Platform), Alexandre Delplace et bien d’autres. Depuis août 2018, Alan Poulain (membre de la core-team et auteur du sous-système GraphQL) a déployé des efforts considérables pour finir ce patch.

Avec 114 commits et 234 fichiers modifiés en presque 3 ans, c'est l'une des plus grandes contributions du projet.

L'intégration de MongoDB repose sur Doctrine MongoDB ODM 2.0 (actuellement en version bêta). Pour activer cette fonctionnalité, il suffit d'installer et de configurer DoctrineMongoDBBundle. API Platform va le détecter automatiquement. Créez ensuite une classe mappée avec MongoDB et marquez-la en tant que ressource API :


namespace App\Document;
 
use ApiPlatform\Core\Annotation\ApiResource;
use Doctrine\ODM\MongoDB\Mapping\Annotations as ODM;
 
/**
 * @ApiResource
 * @ODM\Document
 */
class Book
{
    /**
     * @ODM\Id(strategy="INCREMENT", type="integer")
     */
    public $id;
 
    /**
     * @ODM\Field(type="string")
     */
    public $title;
}

La prise en charge de MongoDB exploite la flexibilité d’API Platform : elle a été implémentée en tant que fournisseur de données et persisteur de données. Les relations, la pagination ainsi que les filtres booléens, les dates, les nombres, les ordres, et les filtres de recherche sont également pris en charge !

Un grand merci à tous les contributeurs de cette fonctionnalité, ainsi qu’à Andreas Braun, responsable de la maintenance de Doctrine MongoDB ODM, pour ses relectures approfondies !

Lisez et améliorez la documentation relative à MongoDB.

Support de Elasticsearch

Elasticsearch est un outil Open Source permettant d'effectuer des recherches et des analyses avancées sur un très grand nombre de données. La société Orange a sponsorisé le développement du support d’Elasticsearch pour API Platform, ainsi que d’intéressants filtres de recherche. Cette implémentation a été réalisée par Baptiste Meyer (core-team API Platform). Grâce à Orange, cette fonctionnalité est désormais disponible dans la version 2.4 d’API Platform !

Pour activer et configurer le support d’Elasticsearch, reportez-vous à la documentation officielle. Ensuite, une simple classe de ressources correspondant à un index Elasticsearch suffit pour bénéficier de toute la puissance d'API Platform :



namespace App\Model;
 
use ApiPlatform\Core\Annotation\ApiProperty;
use ApiPlatform\Core\Annotation\ApiFilter;
use ApiPlatform\Core\Annotation\ApiResource;
use ApiPlatform\Core\Bridge\Elasticsearch\DataProvider\Filter\MatchFilter;
 
/**
 * @ApiResource
 */
class Tweet
{
    /**
     * @ApiProperty(identifier=true)
     *
     * @var string
     */
    public $id;
 
    /**
     * @var User
     */
    public $author;
 
    /**
     * @var \DateTimeInterface
     */
    public $date;
 
    /**
     * @ApiFilter(MatchFilter::class)
     *
     * @var string
     */
    public $message;
}

Ensuite, vous pouvez utiliser une URL telle que / tweets? Message = foo pour effectuer une recherche à l'aide de Elasticsearch.

Gardez en tête que c’est votre responsabilité d’alimenter votre index Elastic. Pour ce faire, vous pouvez utiliser Logstash, un persisteur de données personnalisé, ou tout autre mécanisme adapté à votre projet (tel qu'un ETL). Baptiste a également profité de cette occasion pour améliorer le code gérant la pagination. Il s'agit désormais d'une classe générique utilisée par tous les fournisseurs de données natifs (Doctrine ORM, MongoDB et Elasticsearch), que vous pouvez réutiliser par vous-même.

Lisez et améliorez la documentation relative à Elasticsearch.

Mise à jour en temps réel du client avec Mercure

Mercure est un tout nouveau protocole basé sur HTTP / 2 et les Server-Sent Events (SSE). C’est une alternative moderne à WebSocket (WebSocket n’étant pas compatible avec HTTP / 2). Mercure est particulièrement utile pour publier en temps réel les mises à jour des ressources servies via des API Web. Il est supporté nativement par les navigateurs modernes (aucune bibliothèque requise ni SDK) et est très utile pour mettre à jour des applications Web et mobiles réactives.

Dans la version 2.4, nous avons ajouté la prise en charge de Mercure au composant serveur d'API Platform et aux générateurs d'applications React et React Native. La configuration de Docker Compose fournie avec API Platform a également été mise à jour pour fournir un hub Mercure. La configuration pour l'envoi automatique des mises à jour aux clients actuellement connectés est très simple :


namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(mercure=true)
 */
class Book
{
    // ...
}

Grâce aux fonctionnalités de découverte automatique de Mercure, les clients générés s'abonnent automatiquement aux mises à jour :

Mercure API

Découvrez le protocole Mercure.

CQRS et traitement des messages asynchrones avec Symfony Messenger

Messenger est un nouveau composant Symfony créé par Samuel Roze (core team Symfony et API Platform). Il permet de distribuer des messages à l'aide de queues de messages (RabbitMQ, Kafka, Amazon SQS, Google PubSub…) et de les traiter de manière asynchrone. Il fournit un bus de messages permettant de mettre en œuvre le modèle de conception CQRS. Dans API Platform 2.4, nous avons ajouté un moyen pratique de tirer parti des fonctionnalités de Messenger. Cette nouvelle fonctionnalité est particulièrement utile pour créer des endpoints orientés service (de type RPC) :


namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use Symfony\Component\Validator\Constraints as Assert;

/**
 * @ApiResource(
 *     messenger=true,
 *     collectionOperations={
 *         "post"={"status"=202}
 *     },
 *     itemOperations={},
 *     outputClass=false
 * )
 */
class ResetPasswordRequest
{
    /**
     * @var string
     *
     * @Assert\NotBlank
     */
    public $username;
}

Grâce au nouvel attribut Messenger, cet objet sera automatiquement envoyé au bus. Il peut ensuite être traité (de manière synchrone ou asynchrone) par un gestionnaire de messages :

 
namespace App\Handler;

use App\Entity\ResetPasswordRequest;
use Symfony\Component\Messenger\Handler\MessageHandlerInterface;

class ResetPasswordRequestHandler implements MessageHandlerInterface
{
    public function __invoke(ResetPasswordRequest $forgotPassword)
    {
        // do something with the resource
    }
}

Et c’est tout ! Voilà ce qu’il vous faut pour utiliser le composant Messenger avec API Platform.

Lisez et améliorez la documentation du sous système de Messenger.

Serveur Push

HTTP/2 permet à un serveur d’envoyer de manière préventive (ou «push») des réponses (ainsi que les demandes «promises» correspondantes) à un client en association avec une requête précédente envoyée par le client. Cela peut être utile lorsque le serveur sait que le client doit disposer de ces réponses pour traiter pleinement la réponse à la requête initiale (RFC 7540).

Cette fonctionnalité est particulièrement utile pour les performances des API REST : elle permet au serveur d’envoyer (push) instantanément les relations de la ressource actuelle dont le client aura besoin, avant même que le client sache qu'il devra émettre une requête HTTP supplémentaire.

API Platform 2.4 facilite grandement l'établissement de relations utilisant HTTP/2 :


namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiProperty;
use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource
 */
class Book
{
    /**
     * @ApiProperty(push=true)
     *
     * @var Author
     */
    public $author;
}

Grâce à l'attribut push, si le client demande / books / 1, le serveur web enverra directement à la fois la ressource du livre demandée et l'auteur associé (par exemple, / authors / 12) au client. Pour de meilleures performances, cette fonctionnalité doit être utilisée avec le système d'invalidation de cache HTTP intégré (basé sur Varnish).

Lisez et améliorez la documentation du sous-système HTTP / 2 Server Push.

Détection de filtres dans API Platform Admin

Jean-François Thuillier et Arnaud Oisel ont patché API Platform Admin et la bibliothèque JavaScript API Doc Parser sous-jacente pour détecter et utiliser automatiquement les filtres exposés par les spécifications de l'API (Hydra ou OpenAPI). Regardez par vous-même :

admin demo

Le seul code dont vous avez besoin pour obtenir une telle interface est le suivant :


import React from 'react';
import { HydraAdmin } from '@api-platform/admin';

export default () => <HydraAdmin entrypoint="https://api.example.com"/>;

L'interface utilisateur est construite côté client de manière dynamique en analysant les spécifications de l'API.

Jean-François a également ajouté quelques helpers pour aider à la personnalisation de l’admin, et Laury Sorriaux a corrigé une limitation de longue date : il est désormais possible d’utiliser l’admin même avec une API non desservie à la racine du domaine (telle que / api).

Découvrez et améliorez la documentation d’API Platform Admin.

OpenAPI v3 et ReDoc

API Platform 2.4 prend désormais en charge la nouvelle version du format de spécification OpenAPI (anciennement Swagger) (v3). Notre framework utilise également les nouvelles fonctionnalités introduites par cette version, telles que les liens.

Pour récupérer la spécification d’une version donnée d’OpenAPI de l'API, utilisez l'URL suivante : /docs.json?spec_version=3.

Vous pouvez également extraire la spécification au format JSON ou au format YAML :

bin / console api: openapi: export --spec-version = 3 # JSON
bin / console api: openapi: export --spec-version = 3 --yaml # YAML

Parallèlement à Swagger UI, nous avons implémenté la prise en charge de ReDoc, un générateur de docs d’API, écrit en React :

redoc

Anthony Grassiot (membre de la core-team API Platform) a apporté une aide considérable au support d’OpenAPI v3. L'intégration de ReDoc a été réalisée par Grégoire Hébert. Un grand merci à eux !

Découvrez et améliorez la documentation relative à OpenAPI.

Prise en charge améliorée du DTO

La gestion des objets de transfert de données était connue pour être difficile avec API Platform. En octobre dernier, une partie de l’équipe d’API Platform et de Sylius ont collaboré pour améliorer l'API de ce framework e-commerce basé sur Symfony, avec l’aide d’API Platform (on vous en dira bientôt plus à ce sujet !). Au cours de cet atelier, Antoine Bluchet et Kévin Dunglas ont travaillé sur une nouvelle façon de gérer les DTO avec API Platform :


namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use App\Dto\BookInput;
use App\Dto\BookOutput;

/**
 * @ApiResource(
 *   inputClass=BookInput::class,
 *   outputClass=BookOutput::class
 * )
 */
final class Book
{
  // ...
}

Les nouveaux attributs input_class et output_class permettent d’utiliser des classes spécifiques respectivement pour la représentation en écriture et en lecture de la ressource.

Comme illustré dans l'exemple utilisant Symfony Messenger, il est également possible de définir ces nouveaux attributs sur false pour indiquer que l'opération ne prendra aucune entrée ni aucune sortie. Ces nouveaux attributs sont automatiquement pris en compte par tous les sous-systèmes d’API Platform, incluant GraphQL, Hydra et OpenAPI.

Découvrez et améliorez la documentation relative au DTO.

Cache HTTP headers

Un moyen simple de configurer le cache HTTP par ressource a été ajouté par Daniel West :


use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(cacheHeaders={"max_age"=60, "shared_max_age"=120})
 */
class Book
{
    // ...
}

Avec cette configuration, API Platform générera automatiquement l'en-tête HTTP Cache-Control suivant : Cache-Control: max-age = 60, public, s-maxage = 120. Un grand merci à Daniel !

Lisez et améliorez la documentation des en-têtes de cache HTTP.

Sunset HTTP header

Le header de réponse HTTP Sunset indique qu'une URI peut très certainement ne plus répondre à un moment spécifique dans le futur (draft-wilde-sunset-header Internet Draft).

Cet en-tête fonctionne bien avec le mécanisme de dépréciation disponible depuis API Platform 2.3. Grâce au travail de Thomas Blank, il est maintenant facile de définir cet en-tête à l’aide de API Platform :


namespace App\Entity;

/**
 * @ApiResource(itemOperations={
 *     "get"={
 *         "deprecation_reason"="Retrieve a Book instead",
 *         "sunset"="01/01/2020"
 *     }
 * })
 */
class Parchment
{
    // ...
}

Découvrez et améliorez la documentation.

Générateur de client amélioré

API Platform 2.4 est livré avec une version améliorée des générateurs de clients React et Vue.js :

Les relations sont maintenant toujours traitées correctement
Les champs HTML de type nombre ainsi que les listes (arrays) sont convertis avec le type JSON approprié lors de leur envoi à l'API
Les API non serveur à la racine du domaine (comme / api) sont maintenant supportées (grâce à Fabien Kovacic)

Aidez-nous à promouvoir API Platform !

API Platform 2.4 est disponible sur GitHub. Aidez-nous à améliorer continuellement ce projet en y contribuant. Vous pouvez également lui donner une étoile sur Github ou suivre Webby sur Twitter !

Notre actu

API Platform 2.4 beta : MongoDB, Elasticsearch, Mercure, Symfony Messenger et bien plus !

Un projet à concrétiser

Contact

Restons connectés

Dernier tweet