Comment créer et déployer une API REST avec l’IA sur Adios

Aidez-moi à planifier une API REST conçue pour la production dans cet espace de travail Adios. Ne modifiez pas encore les fichiers.

L’API :
- Nom : [NOM DE L’API]
- Utilisateur : [APPLICATION WEB, APPLICATION MOBILE, OUTIL INTERNE OU PARTENAIRE]
- Ressource principale : [RESSOURCE]
- Actions principales : [CRÉER, LISTER, LIRE, MODIFIER OU AUTRES ACTIONS]
- Authentification : [AUCUNE POUR UNE DÉMO PUBLIQUE, JETON UTILISATEUR OU CLÉ API DE SERVICE]
- Base de données : [BASE DE DONNÉES ACTUELLE DU PROJET OU POSTGRES]

Avant de proposer des modifications, examinez le dépôt, le framework actuel, le gestionnaire de packages, les tests, la route de contrôle de santé, la configuration d’environnement et adios.yaml.

Présentez :
1. le tableau des routes avec les méthodes et les codes de réponse ;
2. les formats des requêtes et des réponses ;
3. la validation et la gestion des erreurs ;
4. le modèle de données et l’approche de migration ;
5. les périmètres d’authentification et d’autorisation ;
6. les considérations de limitation du débit et de prévention des abus ;
7. les tests automatisés et les exemples curl manuels ;
8. la configuration Adios requise pour l’environnement d’exécution, la santé, la base de données et les secrets.

Privilégiez la stack existante. Expliquez toute nouvelle dépendance. Attendez mon approbation avant toute modification.

Créez l’API REST à partir du plan que j’ai approuvé.

Exigences :
- Conservez le langage, le framework, le gestionnaire de packages et les fichiers de déploiement Adios existants.
- Préservez un endpoint léger de contrôle de santé, accessible sans authentification et n’exposant aucune donnée privée.
- Validez toutes les entrées externes et renvoyez les erreurs dans un format JSON unique et cohérent.
- Appliquez l’authentification et les autorisations côté serveur lorsque le plan l’exige.
- Utilisez des accès paramétrés à la base de données via la couche de données déjà établie dans le projet.
- Ajoutez des migrations réversibles si ce dépôt utilise des migrations.
- Ne codez jamais d’identifiants en dur. Référencez les valeurs de base de données et d’authentification par leur nom de variable d’environnement.
- Ajoutez une documentation concise de l’API et des exemples de requêtes exécutables.
- Ajoutez des tests pour le cas nominal, les entrées invalides, les enregistrements manquants, les accès non autorisés et un scénario d’échec de base de données testable sans risque.
- Exécutez le formateur, le linter, les tests et la commande de compilation de production déjà utilisés par le projet.

À la fin, donnez-moi le tableau des routes, les fichiers modifiés, les résultats des tests, la configuration Adios requise et les commandes exactes à exécuter sur l’aperçu. Ne déployez pas en production.

Examinez cette API comme si un client inconnu allait l’appeler. Corrigez uniquement les problèmes vérifiés et ne déployez pas.

Vérifiez :
- que les routes utilisent les méthodes HTTP et les codes de statut prévus ;
- que les entrées mal formées, manquantes, trop volumineuses ou inattendues sont rejetées sans risque ;
- que l’authentification ne peut pas être contournée et qu’un appelant ne peut pas accéder aux données protégées d’un autre ;
- que les réponses d’erreur n’exposent ni traces de pile, ni secrets, ni détails de base de données, ni chemins internes ;
- que les requêtes répétées restent sans risque lorsqu’une opération doit être idempotente ;
- que les écritures en base et les migrations sont cohérentes ;
- que la documentation de l’API et les exemples de requêtes correspondent à l’implémentation ;
- que les contrôles de santé restent légers ;
- que les journaux sont utiles sans enregistrer d’identifiants ni de corps de requête sensibles ;
- que tous les contrôles de formatage, de lint, de test et de compilation réussissent.

Présentez un tableau des contrôles et de leurs éléments de vérification, les requêtes exactes à exécuter dans l’aperçu et les risques restants.

Préparez cette API pour une vérification de déploiement Adios. Ne déployez pas avant mon approbation.

Confirmez la commande de démarrage, l’hôte et le port d’écoute, le chemin de contrôle de santé, les noms des variables d’environnement requises, la dépendance à la base de données, la commande de migration et la route publique attendue. Comparez-les à adios.yaml et signalez toute divergence.

Donnez-moi ensuite :
1. les résultats finaux des contrôles automatisés ;
2. cinq requêtes de test de bon fonctionnement sans risque pour l’URL de l’aperçu ;
3. une note de retour arrière ou de restauration en cas de migration échouée ;
4. les secrets à configurer dans Adios plutôt que dans le code source ;
5. un contrôle après déploiement couvrant la santé, les journaux, l’authentification et un cycle d’écriture et de lecture.

Arrêtez-vous pour obtenir mon approbation avant le déploiement en production.