Produits Entr'ouvert » Passerelle

jenkins en erreur mais je n'ai pas regardé.

Sur le fond, ça me semble très spécifique au cas de cette montée de version api entreprise, je n'envisage pas d'utilité générale, ça pourrait pas juste rester spécifique et en haut des quelques endpoints y ajouter des if pas la bonne version: raise BadRequest('mauvaise version').

?

il y a pas mal de endpoints dans v2 et dans v3, ça fera une page d'accueil assez indigeste je trouve sans cette fonctionnalité.

Mais c'est une conséquence de la décision de ne pas faire du connecteur une couche de compatibilité intra-versions. (passons, j'accepte)

(bref perso pas enthousiaste, parce que je ne vois pas encore de généralisation, mais sans doute aussi parce que je regrette encore cette décision).

(et cela posé, je laisse ce ticket et les relectures/décisions à d'autres)

J'ai du mal à voir l'utilité, en vrai on va avoir les endpoints v2 et v3 en parallèle sur API entreprise pendant 1 an si j'ai bien compris, personne ne pourra tester les deux en même temps sauf à jongler sur la configuration du connecteur ? J'ai l'impression que c'est plus chiant qu'autre chose. De plus il ne me semble pas qu'on ait tant de endpoints que ça, on est loin de couvrir tout ce qu'expose API entreprise.

Si le plan c'est d'ajouter des endpoints v3, je verrai plutôt un patch pour pouvoir marquer des endpoints comme étant dépréciés avec une date de retrait prévu, si le but c'est d'adapter les endpoints pour fonctionner avec les deux versions alors on a pas besoin de ça... Je suis dubitatif moi aussi.

Benjamin Dauvergne a écrit :

personne ne pourra tester les deux en même temps sauf à jongler sur la configuration du connecteur ?

Une instance du connecteur en v2, une deuxième en v3. Et tu peux progressivement adapter tes démarches, en allant taper sur l'instance v3, me suis-je imaginé.

Ça vise aussi le futures version d'api entreprise dont la doc de migration dit :

Avec la V.3 : Toutes les API pourront évoluer indépendamment les unes des autres. Les anciennes versions resteront toujours disponibles. Le numéro de version devient donc un paramètre de l’appel et non plus une valeur fixe pour toutes les API.

C'est un peu flou mais j'imagine que des nouveaux endpoints vont apparaître en v4 et encore d'autres en v5 et que c'est raccord avec le fait de pouvoir faire apparaitre/disparaitre des endpoints de connecteur selon une version.

Emmanuel Cazenave a écrit :

Ça vise aussi le futures version d'api entreprise dont la doc de migration dit :

Sincèrement je pense que d'ajouter les endpoints v3 là tout de suite est une bonne idée plutôt que de rester coincé sur une discussion sans fin. Mais figer le fonctionnement sur ces histoires de version me semble prématuré, on pourra vivre avec une ribambelle de endpoint, sans jonglet sur deux connecteurs utilisant le même code mais configuré différemment. Je pense juste nécessaire d'ajouter à la description un marqueur v2/v3 ou le marqueur de déprécation dont je parle plus haut (ça ça me semble réutilisable), que ce soit juste de la doc.

Avec la V.3 : Toutes les API pourront évoluer indépendamment les unes des autres. Les anciennes versions resteront toujours disponibles. Le numéro de version devient donc un paramètre de l’appel et non plus une valeur fixe pour toutes les API.

C'est un peu flou mais j'imagine que des nouveaux endpoints vont apparaître en v4 et encore d'autres en v5 et que c'est raccord avec le fait de pouvoir faire apparaitre/disparaitre des endpoints de connecteur selon une version.

C'est encore pire, on va vouloir taper en v3 sur un endpoint et v4 sur un autre :/ Et certainement que si ça évolue beaucoup, nos utilisateurs le voudront, en attendant faut juste prévoir un paramètre ?version= sur tous les endpoints v3, non ? Par défaut à 3 si j'ai bien compris.

Et Marie, de passage au bureau :

ah bon pourquoi c'est rejeté, alors on va avoir un connecteur blindé de endpoints, ça va être méga relou

Et il y a un paramètre display_category sur @endpoint, qui permettrait de séparer les v2 des v3.