Reprendre le mapping des objets métier sur l'api public

[alexisjanvier]

Nous avons pris le partie faire une api la plus standard et ouverte que possible. C'est pour cela que nous avons choisi API Plateforme afin d'exposer facilement une API respectant la spécification Hydra

Hydra simplifies the development of interoperable, hypermedia-driven Web APIs

Nous avons donc aussi respecté un schéma de données suivant les modèles définis dans schema.org . Et cela marche plutôt bien du point de vue respect des standards.

Vous pouvez tester en choppant de la donnée en curl :

curl -X GET "https://api.caen.camp/api/events?page=1&itemsPerPage=30" -H  "accept: application/ld+json"

Et en la testant à cette adresse : https://search.google.com/test/rich-results

Sauf que le modèle des événements décrit sur schema.org ne correspond pas à notre modèle métier de gestion des CaenCamp !

Pas grave, ce problème est standard et d'ailleurs très vite abordé dans la documentation d'api plateforme : https://api-platform.com/docs/core/design/

Nous avons donc mis en place un modèle de données persisté en base correspondant à notre modèle métier que nous mappons ensuite sur le schéma des événements exposé par l'API.

Mais c'est là qu'est le problème ! Pour avancer et par méconnaissance, ce mapping a été implémenté assez salement via des Data Providers : https://github.com/CaenCamp/api-caencamp/blob/main/src/DataProvider/EventItemDataProvider.php

Si cela nous a permis d'exposer les données existantes, nous avons perdu au passage la capacité de paginer, de trier et de filtrer les listes de résultats retournées par l'API !

Il faut donc maintenant mettre en place un mécanisme propre nous permettant d'avoir pour les événements une liste :

• paginable
• triable par date
• filtrable par date, lieu, organisateur, speaker et titre

A priori, l'utilisation de Dtos semble une approche préconisée par API Platform.