Gato
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>
34 lines
1.4 KiB
Markdown
34 lines
1.4 KiB
Markdown
# 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.
|