Skip to content
Extraits de code Groupes Projets

[16.0] refactor api Enedis

Bonjour @benjamin-filament @julien-filament j'ai pas mal retravaillé ce module parce qu'il y avait pas mal de choses qui ne me plaisaient pas. Est-ce que vous pourriez s'il vous plaît y jeter un oeil et me faire vos retours (de savoir si ça vous paraît une bonne idée de le réorganiser comme ça ou pas) ?

J'ai notamment fait les modifs suivantes :

  • renommage des tables enedis en enedis_acc parce que spécifique à l'API ACC d'Enedis
  • remontée des name (= numéro de l'opération Enedis) / client_id / secret_id sur le modèle API abstract, suppression du passage des paramètres correspondants dans les fonctions (il les récupère avec self.xx) et remontée de la fonction _check_access_api()
  • déplacement du token du backend vers l'API (car les client_id / secret_id / token) sont spécifiques par opération, pas pour tout le backend
  • ajout de l'expiration du token (avec les données remontées par l'API - 3,5h par défaut), je me suis inspiré de ce qui avait été fait sur api_whattheshop pour ça, merci Benjamin !
  • ajout des URIs pour authentification et ACC dans le backend et suppression des variables dans le code
  • remontée du message d'erreur API si présent sur une HTTPError
  • remontée de la fonction

Enfin, pour moi ce module doit être spécifique aux API d'autoconsommation collective (même si l'authentification sera potentiellement commune avec d'autres API - mais pas les identifiants), et pas générique à Enedis, du coup je propose de le renommer api_enedis_acc.

Rapports de requête de fusion

Loading
Loading

Activité

Filtrer l'activité
  • Approbations
  • Assignés et relecteurs
  • Commentaires (des bots)
  • Commentaires (des utilisateurs)
  • Branches et validations
  • Modifications
  • Labels
  • État de verrouillage
  • Mentions
  • État de la demande de fusion
  • Suivi
Veuillez vous inscrire ou vous connecter pour répondre
Chargement en cours