Créer une API de simulation

[johangirod]

Pour pouvoir utiliser les règles du package 'modele-social' sous forme d'une API rest

[mquandalle]

CR Réunion API

Design de l'API

Pour le swagger 3 possibilités discutées :

1. une spécification qui ne contient pas de domaine métier (nom des règles, typage des valeurs) avec un point d'entrée unique POST /calculate à la https://legislation.fr.openfisca.org/swagger. Cette approche impose de documenter l'appel à l'API ailleurs, par exemple donner des exemples d'appels HTTP dans la documentation générée par publicodes — ou sur un outil tiers.
   D'autres points d'entrés génériques sont possibles aussi, comme GET /rules pour avoir la liste des règles ou POST /trace pour avoir la liste de toutes les variables intermédiaires.
2. la même chose qu'au dessus (point d'entrée générique POST /calculate) mais avec le typage des paramètres qui contient le nom des règles
3. ou bien avoir des points d'entrée qui correspondent aux noms des règles

Besoin à clarifier :

• pouvoir donner plusieurs objectifs à la fois ?
• accès aux 200 règles ou seulement à un sous ensemble marqué comme “public” ?
• format de la situation d'entrée : notation pointée ou objets imbriqués ?
• fonctionnement du cache ?

Urssaf

Côté Urssaf a été évoqué le référencement de l'API sur https://portailapi.urssaf.fr/fr/
(et non sur https://open.urssaf.fr qui est dédié à l'ouverture des données ce qui n'est pas l'objet de notre API, même si un lien texte est toujours possible)

Possibilité de tester le déploiement d'une appli nodejs simplifiée sur leur environnement de dev

À nous de revenir vers eux une fois qu'on a une demo disponible

[mquandalle]

Un peu dans l'esprit de #1855 on pourrait aussi se dire que la liste des objectifs est codée en dur, et que plusieurs listes d'objectifs sont disponibles sur plusieurs points d'entrée. Ces points d'entrée pourraient correspondre aux simulateurs : /salarie, /independant

[johangirod]

Après réflexions, je suis d'avis d'avis de partir sur la spécification n°1, dans un premier temps en tout cas, à savoir : un swagger générique.

Je verrai les points d'entrée suivants, pour être au plus proche de l'API de la librairie déjà documentée et disponible :

• GET /rules : liste l'ensemble des règles disponibles dans la base de règle (avec fonction de recherche ?)
• GET /rules/{id} : les informations sur une règle telle qu'on peut les obtenir sur une page de doc (description, titre, note, variables utilisées, règles enfants)
• POST /evaluate : qui prend comme arguments la situation et une expression publicodes à évaluer. Cette dernière peut être sous forme de liste : dans un premier la logique d'évaluation des listes sera codée en dur dans l'API, mais elle utilisera les listes natives de publicodes quand elles seront implémentées.

Le retour de la fonction evaluate devrait être un objet JSON contenant l'evaluation.

Cette API pourrait être fournie sous forme de middleware express par un paquet publicodes-api instancié avec la base de règle de mon-entreprise.

Points d'entrés spécifiques

La possibilité d'avoir des points d'entrés spécifiques avec les objectifs codés en dur est effectivement intéressante et est nécessaire pour activer un contexte avec une situation spécifique (comme sur les simulateurs du site). On souhaiterait éviter que la logique de désactivation / activation de partie des règles soit à la charge de l'utilisateur. Cela n'est pas trop compliqué à ajouter comme logique.

Piste exploratoire

L'autre solution pour éviter d'avoir une surcouche applicative à l'API serait de créer des règles dans un espace de nom simulateur qui contiennent la liste des objectifs avec les remplacements opérant dans ce contexte.

Par exemple on pourrait avoir :

simulateur . auto-entrepreneur : 
  valeur: 
    - chiffres d'affaires
    - auto-entrepreneur . cotisations
    - net
  remplace: 
    - règle: dirigeant
      par: "'auto-entrepreneur'"

Et il n'y a plus qu'à évaluer /evaluate/simulateur . auto-entrepreneur

Bon, cela demanderait à implémenter les listes. À réfléchir donc...

[mquandalle]

Au autre exemple intéressant : https://wikicarbone.beta.gouv.fr/#/api

[mquandalle]

Fermé par #2138

[github-actions]

Ce ticket vient d'être fermé 🎉

Il est temps de prévenir les utilisateurs qui nous ont fait ce retour :
https://mon-entreprise.zammad.com/#search/tags%3A%231870

Laissez un 👍 quand c'est fait !