c34cc41496
- Dockerfile multi-stage (build eclipse-temurin:25-jdk → runtime) - CI : tests via actions/setup-java puis build & push vers registry Gitea - Trigger Watchtower après push sur main - CLAUDE.md + rules projet (.claude/rules/) - Version build.gradle : 0.0.1-SNAPSHOT → 0.0.1 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1.4 KiB
1.4 KiB
Intégration avec Olhar-webapp (frontend)
Principe
Olhar-API est le backend consommé par Olhar-webapp (Angular). Tout changement d'API susceptible d'impacter le frontend doit être signalé.
Quand créer une issue sur Olhar-webapp
Créer une issue sur https://git.goutailler-olivier.com/Gato/Olhar lorsque :
- Un endpoint change de signature (URL, méthode, corps, réponse)
- Un nouveau champ est ajouté à une réponse existante (à exploiter côté frontend)
- Un endpoint est supprimé ou déprécié
- Un comportement d'erreur change (code HTTP, format du message)
Contenu de l'issue
L'issue doit décrire :
- L'endpoint concerné (méthode + URL)
- Ce qui a changé dans l'API
- L'action attendue côté frontend (adapter l'appel, afficher un nouveau champ, etc.)
- Si un feature flag côté frontend couvrait l'absence de cet endpoint, préciser qu'il peut être retiré maintenant que l'API est disponible (nettoyage du code mock et du flag correspondant)
CORS et sécurité
- Les origines autorisées sont configurées dans
SecurityConfig. - En développement :
http://localhost:4200(Angular dev server). - Ne pas ouvrir
*en production.
Contrat d'API
- Les DTOs de réponse (
interfaces/rest/dto/response/) constituent le contrat public. - Ne jamais modifier un champ existant d'un DTO sans créer une issue sur Olhar-webapp.
- Ajouter des champs est non-cassant ; en supprimer ou en renommer est cassant.