Nous avons le cas de ressources avec beaucoup de sous-ressources comme par exemple un topic avec beaucoup de datasets associés. Nous aimerions créer un dataservice avec beaucoup de datasets associés mais nous rencontrerions le même problème qu'avec les topics.
Je pense que nous sommes tous d'accord sur les points suivants :
Nous ne devrions pas nous bloquer d'insérer ce genre de ressource dans la base de données et nous devrions supporter ce cas d'usage
L'API doit dans tous les cas répondre en un temps raisonnable.
La solution actuelle avec les topics consiste à créer un nouvel endpoint "v2" et de laisser l'endpoint "v1" ne plus répondre dans le cas d'un topic avec beaucoup de datasets (ce qui est un problème)
L'endpoint "v2" des topics remplace le tableau des "datasets" par un objet contenant des informations sur comment récupérer la première page des datasets pour ce topic via un autre endpoint.
Nous pourrions faire la même chose pour les dataservices mais je bloque sur le fait que l'API v1 ne répondra plus dans certains cas (comme par exemple si tu parcours toutes les pages des dataservices, lorsque tu tomberas sur la page qui contient le dataservice "data.gouv.fr" avec des dizaines de milliers de datasets cette page là ne chargera pas). Avec ma compréhension des choses c'est le fonctionnement actuel de l'api v1 des topics, toutes les pages fonctionnent sauf celle qui contiennent le topic d'écologie avec 60000 datasets.
Ma solution préférée : ajouter une limite à 200 datasets sur le retour API. C'est une solution qui a l'avantage d'être simple à implémenter, de n'impacter que les gros dataservices / topics.
Le premier point de blocage pourrait être que l'on fait un breaking change. Personnellement je ne considère pas ça comme un breaking change car au dessus d'un grand nombre de datasets l'API ne répond plus de toute manière. Donc on ne casse pas vraiment un endpoint « fonctionnel ».
Le principal inconvénient à mon avis c'est que ce comportement ne serait expliqué que dans la doc API et que du coup les utilisateurs qui ne regardent pas la doc pourrait croire que ce dataservice n'a « que » 200 datasets alors qu'en réalité il en a beaucoup plus. Pour pallier à ce problème on pourrait rajouter un champs datasets_total dans la réponse API qui contiendra le vrai nombre de datasets. Un utilisateur de l'API attentif pourra se rendre compte que le datasets_total ne match pas le nombre d'élément dans la liste datasets et du coup se renseigner via la doc API sur comment récupérer l'ensemble des datasets de façon paginé via un endpoint dédié /api/1/datasets?dataservice=xxx.
Autre point à prendre en compte, actuellement la liste des datasets ne contient que l'ID, le titre, et quelques URLs concernant le dataset, elle n'est donc de toute manière pas adapté pour par exemple afficher la liste des cartes datasets en dessous d'un dataservice (il faut pour ça passer par l'endpoint paginé /api/1/datasets?dataservice=xxx). Je pense que ça va dans le sens de ma solution qui réduit encore l'importance d'avoir l'ensemble des datasets présent dans le tableau datasets directement.
Nous avons le cas de ressources avec beaucoup de sous-ressources comme par exemple un topic avec beaucoup de datasets associés. Nous aimerions créer un dataservice avec beaucoup de datasets associés mais nous rencontrerions le même problème qu'avec les topics.
Je pense que nous sommes tous d'accord sur les points suivants :
La solution actuelle avec les topics consiste à créer un nouvel endpoint "v2" et de laisser l'endpoint "v1" ne plus répondre dans le cas d'un topic avec beaucoup de datasets (ce qui est un problème)
L'endpoint "v2" des topics remplace le tableau des "datasets" par un objet contenant des informations sur comment récupérer la première page des datasets pour ce topic via un autre endpoint.
Nous pourrions faire la même chose pour les dataservices mais je bloque sur le fait que l'API v1 ne répondra plus dans certains cas (comme par exemple si tu parcours toutes les pages des dataservices, lorsque tu tomberas sur la page qui contient le dataservice "data.gouv.fr" avec des dizaines de milliers de datasets cette page là ne chargera pas). Avec ma compréhension des choses c'est le fonctionnement actuel de l'api v1 des topics, toutes les pages fonctionnent sauf celle qui contiennent le topic d'écologie avec 60000 datasets.
Ma solution préférée : ajouter une limite à 200 datasets sur le retour API. C'est une solution qui a l'avantage d'être simple à implémenter, de n'impacter que les gros dataservices / topics.
Le premier point de blocage pourrait être que l'on fait un breaking change. Personnellement je ne considère pas ça comme un breaking change car au dessus d'un grand nombre de datasets l'API ne répond plus de toute manière. Donc on ne casse pas vraiment un endpoint « fonctionnel ».
Le principal inconvénient à mon avis c'est que ce comportement ne serait expliqué que dans la doc API et que du coup les utilisateurs qui ne regardent pas la doc pourrait croire que ce dataservice n'a « que » 200 datasets alors qu'en réalité il en a beaucoup plus. Pour pallier à ce problème on pourrait rajouter un champs
datasets_totaldans la réponse API qui contiendra le vrai nombre de datasets. Un utilisateur de l'API attentif pourra se rendre compte que ledatasets_totalne match pas le nombre d'élément dans la listedatasetset du coup se renseigner via la doc API sur comment récupérer l'ensemble des datasets de façon paginé via un endpoint dédié/api/1/datasets?dataservice=xxx.Autre point à prendre en compte, actuellement la liste des datasets ne contient que l'ID, le titre, et quelques URLs concernant le dataset, elle n'est donc de toute manière pas adapté pour par exemple afficher la liste des cartes datasets en dessous d'un dataservice (il faut pour ça passer par l'endpoint paginé
/api/1/datasets?dataservice=xxx). Je pense que ça va dans le sens de ma solution qui réduit encore l'importance d'avoir l'ensemble des datasets présent dans le tableaudatasetsdirectement.Voir https://github.com/opendatateam/udata/pull/2913 Voir https://github.com/opendatateam/udata-front-kit/issues/52 Voir https://github.com/datagouv/data.gouv.fr/issues/1467#issuecomment-2355659599