[API] Récupération des valeurs uniques pour les filtres de zones et de navires

[SebM42]

Vu avec @alexphiev :

Pour pouvoir créer les filtres, l'application a besoin de récupérer les listes de valeurs uniques suivantes :

Navires (dim_vessel) :

• type
• length_class
• country_iso3

Zones (dim_zone) :

• category
• sub_category

Idéalement un objet par liste

[rv2931]

ces points sont manquants par contre pour les zones category et subcategory il y a le /api/v1/zones/all/categories mais le "all" n'est pas heureux et prête à confusion. Je vais le modifier pour /api/v1/zones/categories
ça renvoie une liste

[
  {
    "category": "amp",
    "sub_category": "Regional Nature Reserve"
  },
  {
    "category": "amp",
    "sub_category": "Marine Nature Park"
  },
...
]

C'est OK ou je le modifie aussi ? @alexphiev

[rv2931]

Sur quelle philosophie on part sur ces listes, j'en vois 3 grosso modo

• on ne renvoie que les types qui sont utilisées en base dans la dim_xxx. Cela signifie que si on a pas de données alors les listes seront vides
• on renvoie une liste fixée en dure dans le code qui contient du coup tous les types que l'on veut pouvoir filtrer qu'il y ait ou pas des données en base qui les utilisent. L'inconvénient de ça c'est que un nouveau type apparaît du coup on ne peut pas le filtrer voir potentiellement l'afficher selon comme un item inexistant est géré
• on fait un mix des deux à savoir on prévoit dans le code une liste de valeurs à minima, et on la merge avec les valeurs (vessel.type par exemple) qui peuvent être utilisées en base. L'intérêt de cette solution c'est qu'elle présente et l'aventage de présenter les filtres dipsonibles à minima dans tous les cas, et s'il y a des nouveaux types qui apparaissent en base alors ceux-ci seront ajoutés au besoin

[SebM42]

le 1er cas, car aucun intérêt de filtrer sur une valeur qui n existe pas en base

et si la liste d'une table de dimension est vide, le problème sera résolu en allant peupler la table de dimensions

[rv2931]

Livré en production

[rv2931]

A valider si le endpoint categories correspond au besoin, il était déjà existant et liste les couples category/subcategory possibles
il y a donc des valeurs dupbliquées tant category (plusieurs subcategory) que subcategory (même subcategory dans plusieurs category)