Distinction du type de retour en cas d'échec ou de réponse vide

[MarHoff]

La fonction _adresse_searchformat(jsonb) et ses dérivés renvoient un recordset (_adressesearch) vide dans les deux cas suivant:

• Réponse vide de l'API (pas de match trouvé)
• Absence de réponse (échec)

Il conviendrait de modifier le comportement de la fonction afin de distinguer ces deux cas, j'envisage pour l'instant 3 possibilités de résolution:

1. Sans modification du type _adressesearch

• Réponse vide de l'API --> recordset contenant une seule ligne avec tout les champs passés à NULL
• Absence de réponse (échec) --> recordset vide

2. Avec modification du type _adressesearch

• Ajout des colonnes de métadonnées de l'api adresse dans le type _adressesearch "attribution": "BAN", "licence": "ODbL 1.0", "query": "8 bd du port", "type": "FeatureCollection" "version": "draft"
  • Réponse vide de l'API --> recordset contenant les métadonnées de l'api et les autres champs à null
  • Absence de réponse (échec) --> recordset vide

    3. Avec modification du type _adressesearch et champs personnalisés frapi

• Ajout des colonnes de métadonnées de l'api adresse dans le type _adressesearch (voir 2)
• Ajout d'une colonne frapi renvoyant un code d'erreur du point de vue de la fonction: succès, échec, réponse vide
  • Réponse vide de l'API --> recordset contenant le champ frapi et les métadonnées de l'api + les autres champs à null
  • Absence de réponse (échec) --> recordset contenant le champ frapi + les autres champs à null

    Comparaisons des solutions

    L'option 1 ne casse pas l'API et à le mérite d'être moins verbeux que les autres. En revanche il peut être difficile pour un utilisateur de bien comprendre l'état réel des ses requêtes en cas de problème. L'option 2 permet de se caler plus strictement sur le type de retour json de l'API. L'option 3 est la plus verbeuse et nécessiterait de définir clairement les valeurs de retour attendues. Ce travail n'aurait de sens que si l'on envisage de rendre cette colonne d'état transversale à toute les apis gérées dans le futur par frapi.

[MarHoff]

Il semblerait que l'API adresse.gouv.fr à évolué de son coté vers la solution 2 et renvoi désormais des métadonnées en cas d'absence de match. Il faudra donc veiller à adapter les implémentations actuelles déjà en place pour tenir compte de ce changement.

{"type": "FeatureCollection",
"limit": 1,
"query": "27 RUE D ALSACE, MULHOUSE",
"filters": {"postcode": "68052"},
"licence": "ODbL 1.0",
"version": "draft",
"features": [],                                     -->featureset vide
"attribution": "BAN"}