Propriétés manquantes dans objet "Intervention" /Propriétés nommées différemment

[Stephanevg]

Bonjour,

Y a il une raison pour la quel une intervention au sein d'une seance, ne contiens pas les mêmes propriétés que ceux d'une intervention recuprer directement via l'API?

Exemple:

Intervention de Seance:

(source)

Même intervention via API:

Source

Ce qui est un peu dérangeant, c'est que les mêmes données, ont dans chaqu'un des cas un autre nom (Intervention via l'API, et Titre via la Seance).
Il y a peut être une raison derrière ceci qui m'échappe?

J'ai également l'impression que l'objet "Intervention" retourné via la Seance, est plus 'complete' que celle de l'API. Ne devrait-elles pas être identique en terme de contenue?
Au pire, celle de l'API devrait 'logiquement' contenir plus de data que une intervention contenue dans un objet plus complexe tel que 'Seance'. Ou il y a quelque chose qui m'échapes?

cdlt

[RouxRC]

Cela vient du fait que les accès API par "objet" du type https://www.nosdeputes.fr/api/document/OBJECT_TYPE/OBJECT_ID/xml reposent sur un accès bas niveau direct aux champs de l'objet en base sans aucun JOIN complémentaire d'éléments stockés dans d'autres tables comme le nom complet du parlementaire ou les tags associés à l'intervention. À l'inverse le rendu par séance est une requête enrichie ce qui permet d'apporter plus d'éléments.
Effectivement un effort aurait pu être mieux fait pour homogénéiser les noms des champs communs, malheureusement ayant désormais déjà des services reposant sur ces accès, il est un peu délicat de renommer les champs.
Il serait possible à terme d'ajouter des routes spécifiques pour retourner plus d'infos sur une intervention via l'API mais j'ai peur que ce ne soit pas très prioritaire :/

[Stephanevg]

Oui effectivement, je comprends que cela ne soit pas prioritaire. Je cherchais principalement ou trouver les données les plus complètes pour une intervention bien précise. J'aurais naturellement pensé qu'en la désignant directement via l'API j'aurais alors toutes les datas.

Une Route supplémentaire me parait un peu "overkill", car la route en question existe déjà à mon sens. Et cela rendra l'utilisation de l'api juste plus confus à mon avis. Et renommer les champs est naturellement hors de question ;)

Je dis peut être n'importe quoi, mais ca serais pas une solution de créer une vue SQL qui recuprererais toutes les données d'une intervention, et de faire pointer la requete en question sur celle-ci? (Je suis pas un expert SQL, donc au cas ou j'écris des bétises il faut simplement m'ignorer ;))

[RouxRC]

Ce serait une solution envisageable effectivement oui, je ne sais pas exactement comment cela peut s'interfacer dans le framework symfony en l'état mais ce serait une piste. @teymour une idée ?

[teymour]

A part faire une jointure pour récupérer les infos liées à l'intervenant, à la séance et aux tags, je ne vois pas comment faire. Mais ca pourrait être l'occasion de refacotoriser la production des interventions avec celles des séances.

Il faudra qu'on fasse gaffe par contre à bien conserver les champs des deux quitte à avoir de la redondance...

Pour que ce qui est de l'option vue, cette notion n'existe pas dans MySQL/MariaDB.

[Stephanevg]

@teymour Je ne suis vraiment pas un expert MySQL/MariaDB mais est-ce que cela n'est pas ce dont nous aurions besoin?

MariaDB --> https://mariadb.com/kb/en/library/views/
MySQL --> https://dev.mysql.com/doc/refman/5.7/en/views.html

(Il y à peut être quelque chose qui m'échappe?)

De manière générale, pour garder un certaine cohérence au sein de l'API je pense que c'est un mal qui sera tôt ou tard necessaire.