Parkings Visualization

Contexte

Le but de cet exercice est de développer une application serveur exposant une API REST permettant à une application mobile ou un site web d’afficher la liste des parkings à proximité d’un utilisateur.

Contraintes fonctionnelles

• L’application doit pouvoir fonctionner avec différents fournisseurs de données (autres villes, autres formats d’API).
• L’API REST exposée à l’application mobile doit rester stable, quelle que soit la source de données.

---

Architecture et organisation du projet

Le projet est structuré en plusieurs modules pour séparer les responsabilités et faciliter la maintenance :

• ParkingsVisualization-application : module principal hébergeant la configuration générale de l’application et les tests d’intégration.
• ParkingsVisualization-business : contient la logique métier, les modèles internes, ainsi que la stratégie de sélection du fournisseur de données selon le contexte.
• ParkingsVisualization-daorest : implémentations spécifiques aux fournisseurs de données (actuellement uniquement Grand Poitiers).
• ParkingsVisualization-restapi : implémentation de l’API REST définie dans le fichier OpenAPI parking-visualization.yml.

Cette séparation permet d’isoler la logique métier de la couche API et des intégrations fournisseurs.

La sélection du fournisseur de données est réalisée via un header HTTP X-Tenant-ID dans les requêtes.

---

Limitations et points non traités

• Sécurité : pas d’authentification ni gestion des accès. En production, il faudrait intégrer un Identity Provider et sécuriser l’API via JWT, ainsi que gérer de façon sécurisée les API keys (ex : HashiCorp Vault).
• Qualité et tests : les tests unitaires sont superficiels, les tests d’intégration sont plus complets. Dans un contexte professionnel, on intègrerait une CI/CD avec analyse statique (ex : SonarQube).
• Configuration : la configuration est gérée localement, mais il faudrait prévoir une gestion multi-environnement robuste (dev, staging, prod).
• Documentation fonctionnelle : non réalisée

---

Étapes de développement

• Initialisation du projet via Spring Initializr.
• Mise en place du découpage multi-modules.
• Rédaction du fichier OpenAPI YAML décrivant l’API REST.
• Intégration Swagger UI accessible à http://localhost:8080/swagger-ui/index.html.
• Création des environnements et collections Postman pour tests.
• Implémentation des objets métier et de la stratégie de sélection du fournisseur.
• Développement de l’API REST et des appels aux fournisseurs.
• Gestion du multi-tenant via un filtre interceptant le header X-Tenant-ID.
• Écriture des tests unitaires et d’intégration.
• Amélioration de la configurabilité et gestion dynamique des fournisseurs.
• Validation fonctionnelle de l’API.
• Rédaction de cette documentation.

---

Prérequis et installation

• JDK 21
• Maven 3.9.11
• Exécuter mvn clean install pour builder le projet
• Lancer l’application avec mvn -pl ParkingsVisualization-application spring-boot:run ou via votre IDE

L’API sera accessible par défaut sur : http://localhost:8080

---

Exemple d’appels API

Vous pouvez effectuer un appel de test ici :

./call-api.bat

Il utilise le bat prévu ici : call-api.bat

Qui contient ce body :

{
  "position": {
    "latitude": 46.58383455409422,
    "longitude": 0.33779491061805567
  },
  "maxDistance": 500
}

Ainsi que ces headers :

Content-Type: application/json
X-Tenant-ID: poitiers

---

Ressources utiles

Pour aller plus loin, vous pouvez vous constituer un environnement Postman :

• Collection Postman pour tester les endpoints :
  Parkings Visualization.postman_collection.json

• Environnement Postman local :
  Local ParkingsVisualization.postman_environment.json