[intégrée] Prop0023 - Intégrer la gestion des WS REST sortants

Framework OM4 Framework Propositions
,
#1

Statut

  • Code intégré dans la branche 4.7.0.
  • Ticket à créer

Porteur principal : Matthias BROQUET

Porteur secondaire : Jean-Yves MADIER

Résumé

Cette proposition d’évolution consiste à ré-intégrer la gestion des web services sortants REST implémentés dans openADS / openARIA dans le framework.

Motivation

Le besoin de pouvoir faire communiquer des applications openMairie vers d’autres applications par le biais de WS est présent depuis un moment. Une implémentation a été mise en place dans openADS, puis répercutée dans openARIA (code dupliqué).
Afin d’en faciliter la maintenance, et d’en faire profiter le plus grand nombre, un reversement dans le framework semble judicieux.

Pré-requis

N/A

Proposition et implémentation

  • Ré-intégration littérale de ce qui a été fait dans openADS et openARIA, fonctionnalités à l’identique
  • Ré-écriture de tests automatisés, en utilisant une ressource publique de tests (ex : https://jsonplaceholder.typicode.com)

Exclusions

Cette évolution ne comprend pas la ré-intégration :

  1. des WS entrants (évolution distincte à venir),
  2. des WS sortant SOAP (techno vieillissante).

Risques

Aucun risque à les réintégrer telles qu’elles :

  • Fonctionnalités testées automatiquement ;
  • En production depuis plus de 2 ans ;
  • Sans incidence directe sur le framework (librairies mises à disposition pour le développeur).

Expérimentation

Pas de branche à l’heure actuelle, mais l’existant dans les applis métiers cités ci-dessus peut être consulté ici pour openADS et là pour openARIA.

#2

Bonjour,

Si par sortant, on désigne bien des services consommés, qui sont donc extérieurs avec leur propre façon de répondre aux URL, d’un point de vue “exploitant”, il y a peut-être une réflexion à mener sur la répercussion des erreurs dans le fichier error.log censé n’indiquer que des erreurs “système”: requête SQL non conforme, URL racine indisponible, …

Ce serait un vrai plus d’avoir la possibilité pour chaque cas métier de paramétrer les codes HTTP ou motifs d’erreur qui méritent une répercussion dans le fichier error.log ou pas. Pour openARIA, j’ai remplacé cela par un filtre sur error.log pour ignorer les erreur comme:
*SIG: HTTP-400 suite à l’échec d’un POST car les données fournies (aucune le + souvent) n’ont pas permis de géolocaliser, et donc aucune valeur ne peut être retournée
*ADS: HTTP-400 suite à l’échec d’un GET pour retrouver les informations d’un dossier ADS inexistant (valeur en saisie libre dans openARIA)

Ceci dit, j’ai bien vu que votre proposition est une reprise “en l’état”, qui est déjà un vrai plus.