Dans cette section, nous allons explorer l'interface de gestion des API, qui nécessite plusieurs types d'API : une pour DeepL pour gérer la traduction des données, une autre pour contourner les CAPTCHA et une pour l'analyse de texte.

Les sujets abordés dans cette section sont les suivants :

  1. Modèles de base de données
  2. Backend pour la gestion des API
  3. Frontend pour la gestion des API
  4. Tests

Ce chapitre sera simple, car il présente les opérations CRUD de base. CRUD signifie Create, Read, Update et Delete (créer, lire, mettre à jour et supprimer), des opérations fondamentales dans le développement d'applications. En fait, la plupart des applications reposent principalement sur les fonctionnalités CRUD.

Modèles de base de données

Vos modèles se trouvent dans app/database/models.py.

Voici à quoi ressemble votre table pour stocker les API :

class APIs(Base):
    __tablename__ = "apis"
    id = Column(Integer, primary_key=True, index=True)
    api_name = Column(String, unique=True, index=True)
    api_provider = Column(String)
    api_type = Column(String)
    api_key = Column(String)
    model = Column(String)
    prompt = Column(Text)
    max_tokens = Column(Integer)
    timestamp = Column(DateTime, default=datetime.utcnow)
    is_active = Column(Boolean, default=False)

Certaines API incluent un paramètre appelé « température », mais nous ne le stockerons pas ici. D'après mon expérience, la température par défaut de « 0,1 » est suffisante pour la plupart des requêtes. Cependant, vous pouvez faire des essais en ajoutant une colonne « température » à la base de données, ce qui nécessiterait des mises à jour correspondantes à la fois dans le backend et le frontend.

Backend pour la gestion des API

Le code permettant de gérer les API se trouve dans app/routes/manage_api.py. Contrairement à d'autres routes, celle-ci n'utilise aucun service ni module de scraping.

Le script manage_api.py définit les routes FastAPI pour gérer les configurations API (par exemple, DeepL, Anthropic, OpenAI) dans l'application tornet_scraper, en interagissant avec la base de données pour créer, mettre à jour, supprimer, lister et activer les API. Vous trouverez ci-dessous une explication concise de ses principaux composants et fonctionnalités.

Variables globales

  1. logger :
    • Objectif : configure la journalisation pour le débogage et le suivi des erreurs.
    • Détails : utilise le module logging avec le niveau INFO pour consigner les opérations et les erreurs.
  2. manage_api_router :
    • Objectif : routeur FastAPI pour les points de terminaison de gestion des API.
    • Détails : configuré avec le préfixe /api/manage-api et les balises [« API », « API Management »] pour l'organisation.

Modèles Pydantic

  1. DeepLCreateRequest :
    • Objectif : valide les données de la requête POST pour créer une API DeepL.
    • Champs : api_name (str), api_key (str).
  2. IABCreateRequest :
    • Objectif : valide les données de requête POST pour créer une API Anthropic (IAB).
    • Champs : api_name (str), api_key (str), model (str), max_tokens (int), prompt (str).
  3. CaptchaCreateRequest :
    • Objectif : valide les données de la requête POST pour créer une API OpenAI (Captcha).
    • Champs : api_name (str), api_key (str), model (str), max_tokens (int), prompt (str).
  4. UpdateRequest :
    • Objectif : valide les données de la requête PUT pour mettre à jour une API.
    • Champs : api_name (str), api_key (str), model (str, facultatif), max_tokens (int, facultatif), prompt (str, facultatif).

Fonctions

  1. set_active_api :

    • Objectif : active une API spécifique et désactive les autres API du même fournisseur.
    • Paramètres clés :
      • db : SQLAlchemy Session pour les opérations de base de données.
      • api_id : ID entier de l'API à activer.
      • api_provider : chaîne identifiant le fournisseur (par exemple, deepl, anthropic).
    • Retourne : Aucun.
    • Détails : met à jour le champ is_active à False pour toutes les API du même fournisseur, à l'exception de l'api_id spécifié, qui est défini sur True. Valide les modifications dans la base de données.

  2. create_deepl_api :

    • Objectif : Crée une nouvelle configuration API DeepL.
    • Paramètres clés :
      • request : DeepLCreateRequest avec le nom et la clé de l'API.
      • db : SQLAlchemy Session.
    • Retourne : JSONResponse avec un message de réussite.
    • Détails : vérifie s'il existe un doublon api_name, crée une instance de modèle APIs (api_provider=« deepl », api_type=« translation_api »), l'enregistre dans la base de données et renvoie une réponse de réussite. Lève une exception HTTPException (400 pour les doublons, 500 pour les erreurs).

  3. create_iab_api :

    • Objectif : Crée une nouvelle configuration API Anthropic (IAB).
    • Paramètres clés :
      • request : IABCreateRequest avec le nom de l'API, la clé, le modèle, le nombre maximal de jetons et l'invite.
      • db : SQLAlchemy Session.
    • Renvoie : JSONResponse avec un message de réussite.
    • Détails : similaire à create_deepl_api, mais définit api_provider=« anthropic », api_type=« iab_api ». Valide et stocke des champs supplémentaires (model, max_tokens, prompt).

  4. create_captcha_api :

    • Objectif : crée une nouvelle configuration API OpenAI (Captcha).
    • Paramètres clés :
      • request : CaptchaCreateRequest avec le nom de l'API, la clé, le modèle, le nombre maximal de jetons et l'invite.
      • db : SQLAlchemy Session.
    • Retourne : JSONResponse avec un message de réussite.
    • Détails : similaire à create_iab_api, mais définit api_provider=« openai », api_type=« captcha_api ».

  5. list_apis :

    • Objectif : récupère toutes les configurations API.
    • Paramètres clés :
      • db : SQLAlchemy Session.
    • Retourne : Dictionnaire avec une liste d'API (ID, nom, fournisseur, type, clé, modèle, nombre maximal de jetons, invite, horodatage, statut actif).
    • Détails : Interroge tous les enregistrements APIs et les renvoie au format JSON. Génère une exception HTTPException (500) en cas d'erreur.

  6. update_api :

    • Objectif : met à jour une configuration API existante.
    • Paramètres clés :
      • api_id : ID entier de l'API à mettre à jour.
      • request : UpdateRequest avec les champs mis à jour.
      • db : SQLAlchemy Session.
    • Retourne : JSONResponse avec un message de réussite.
    • Détails : vérifie que l'API existe, recherche les doublons api_name, met à jour les champs (uniquement les valeurs non None pour model, max_tokens, prompt) et valide les modifications. Génère une exception HTTPException (404 si introuvable, 400 en cas de doublons, 500 en cas d'erreur).

  7. delete_api :

    • Objectif : supprime une configuration API.
    • Paramètres clés :
      • api_id : ID entier de l'API à supprimer.
      • db : SQLAlchemy Session.
    • Renvoie : JSONResponse avec un message de réussite.
    • Détails : vérifie que l'API existe, la supprime de la base de données et valide. Génère une exception HTTPException (404 si introuvable, 500 en cas d'erreur).

  8. activate_api :

    • Objectif : active une API spécifique, désactivant les autres du même fournisseur.
    • Paramètres clés :
      • api_id : ID entier de l'API à activer.
      • db : SQLAlchemy Session.
    • Retourne : JSONResponse avec un message de réussite.
    • Détails : vérifie que l'API existe, appelle set_active_api pour basculer is_active et renvoie un message de réussite. Lève une exception HTTPException (404 si introuvable, 500 en cas d'erreur).

  9. get_api :

    • Objectif : récupère une seule configuration API par ID.
    • Paramètres clés :
      • api_id : ID entier de l'API.
      • db : SQLAlchemy Session.
    • Retourne : Dictionnaire contenant les détails de l'API (ID, nom, fournisseur, type, clé, modèle, nombre maximal de jetons, invite, horodatage, statut actif).
    • Détails : interroge la table APIs pour l'ID spécifié et renvoie ses détails. Lève une exception HTTPException (404 si introuvable, 500 en cas d'erreur).

Interface utilisateur pour la gestion des API

Le code de l'interface utilisateur se trouve dans app/templates/manage_api.html.

Le modèle manage_api.html étend base.html pour fournir une interface utilisateur permettant de gérer les configurations API (DeepL, IAB/Anthropic, Captcha/OpenAI) dans l'application tornet_scraper. Il interagit avec le backend via des appels API pour créer, mettre à jour, supprimer, répertorier et activer des API. Vous trouverez ci-dessous une explication concise de ses principales fonctionnalités et de leur interaction avec le backend.

  1. Héritage du modèle :

    • Objectif : exploite la mise en page base.html pour garantir une structure cohérente.
    • Interaction avec le backend : hérite de la barre de navigation et de la gestion des messages flash de base.html. Définit le titre de la page sur « API Management » via {% block title %}. Les données API initiales (apis) sont transmises depuis main.py::manage_api et affichées dans le tableau à l'aide de Jinja2. Les messages flash provenant du backend (stockés dans la session) sont affichés dans le conteneur hérité.

  2. Création d'API :

    • Objectif : permet aux utilisateurs d'ajouter de nouvelles configurations API pour les services DeepL, IAB ou Captcha.
    • Interaction avec le backend :
      • Trois boutons (« Ajouter une API DeepL », « Ajouter une API IAB », « Ajouter une API Captcha ») ouvrent les modaux correspondants (addDeepLModal, addIABModal, addCaptchaModal) via openModal().
      • Chaque modal contient un formulaire avec les champs obligatoires (par exemple, api_name, api_key pour DeepL ; model, max_tokens, prompt supplémentaires pour IAB/Captcha).
      • La soumission du formulaire déclenche createDeepLAPI(), createIABAPI() ou createCaptchaAPI(), qui envoient des requêtes AJAX POST à /api/manage-api/create/deepl, /iab ou /captcha (gérées par manage_api.py::create_deepl_api, create_iab_api, create_captcha_api).
      • Le backend valide la requête (à l'aide de modèles Pydantic), vérifie s'il existe des doublons api_name, enregistre l'API dans la table APIs et renvoie un message de réussite. En cas de réussite, un message flash s'affiche, la fenêtre modale se ferme, le formulaire est réinitialisé et la table est mise à jour. Les erreurs déclenchent un message d'erreur flash.

  3. Affichage et mise à jour du tableau des API :

    • Objectif : affiche une liste dynamique des API avec leur statut en temps réel.
    • Interaction avec le backend :
      • Le tableau est initialement rempli avec les apis de main.py::manage_api, qui indiquent le type d'API, son nom, sa date de création et son statut d'activité.
      • La fonction updateTable() s'exécute toutes les 10 secondes (via setInterval) et après les actions de création/mise à jour/suppression/activation, en envoyant une requête AJAX GET à /api/manage-api/list (gérée par manage_api.py::list_apis).
      • Le backend interroge la table « APIs » et renvoie une liste JSON des API (ID, nom, fournisseur, type, clé, modèle, nombre maximal de jetons, invite, horodatage, statut actif). La table est actualisée avec ces données, affichant les badges « Active » ou « Inactive ». Les erreurs déclenchent un message d'erreur flash.

  4. Modification de l'API :

    • Objectif : met à jour les configurations API existantes.
    • Interaction avec le backend :
      • Chaque ligne du tableau comporte un bouton « Modifier » qui appelle openEditModal(apiId), envoyant une requête AJAX GET à /api/manage-api/get/{api_id} (gérée par manage_api.py::get_api).
      • Le backend renvoie les détails de l'API, qui remplissent le formulaire editAPIModal. Pour les API DeepL, seuls les champs api_name et api_key sont affichés ; pour IAB/Captcha, les champs supplémentaires model, max_tokens et prompt sont affichés.
      • La soumission du formulaire déclenche updateAPI(), qui envoie une requête AJAX PUT à /api/manage-api/update/{api_id} (gérée par manage_api.py::update_api) avec les champs mis à jour. Le backend valide et met à jour la table APIs, puis renvoie un message de réussite. En cas de réussite, un message flash s'affiche, la fenêtre modale se ferme et la table est mise à jour. Les erreurs déclenchent un message d'erreur flash.

  5. Suppression d'API :

    • Objectif : supprime une configuration API.
    • Interaction avec le backend :
      • Chaque ligne du tableau comporte un bouton « Supprimer » qui appelle openDeleteModal(apiId), ouvrant le deleteAPIModal avec l'ID API stocké dans un champ caché.
      • Le bouton « Supprimer » déclenche confirmDeleteAPI(), qui envoie une requête AJAX DELETE à /api/manage-api/delete/{api_id} (gérée par manage_api.py::delete_api).
      • Le backend vérifie que l'API existe, la supprime de la table APIs et renvoie un message de réussite. En cas de réussite, un message flash s'affiche, la fenêtre modale se ferme et la table est mise à jour. Les erreurs déclenchent un message d'erreur flash.

  6. Activation de l'API :

    • Objectif : active une API spécifique, désactivant les autres API du même fournisseur.
    • Interaction avec le backend :
      • Chaque ligne du tableau comporte un bouton « Activer » (désactivé si déjà actif) qui appelle activateAPI(apiId, apiType), envoyant une requête AJAX POST à /api/manage-api/activate/{api_id} (gérée par manage_api.py::activate_api).
      • Le backend appelle set_active_api pour définir is_active=True pour l'API spécifiée et False pour les autres API du même fournisseur, en validant les modifications dans la table APIs. En cas de succès, un message flash s'affiche et la table est mise à jour. Les erreurs déclenchent un message d'erreur flash.

Bien que l'utilisation d'Anthropic ou d'OpenAI ne soit pas obligatoire, j'ai simplifié le processus pour plus de simplicité. Dans une autre application, j'ai implémenté la prise en charge de quatre fournisseurs différents, offrant des dizaines de modèles. Cependant, ce niveau de flexibilité est souvent inutile, car il ajoute de la complexité au code du backend.

Test

Voici comment vous pouvez ajouter deux API DeepL mais n'en activer qu'une seule à la fois.

Test de gestion des API