Update swagger.yaml #6
Conversation
mrongier
commented
Feb 6, 2020
mrongier
commented
- sur la base du fichier swagger, on re-propose la solution bytel, en mettant à jour le numéro de version.
- On supprime l'attribut url dans l'objet photo. en effet le link nous permet d'aller vers la photo.
- sur la base du fichier swagger, on re-propose la solution bytel, en mettant à jour le numéro de version. - On supprime l'attribut url dans l'objet photo. en effet le link nous permet d'aller vers la photo.
mrongier
requested review from
aminvielledebat,
NicolasD-Altitude,
MARIEPHAM,
cmergen,
vpouchard-free and
kosc-si
There was a problem hiding this comment.
Merci pour la PR @mrongier.
En plus de ma remarque sur le path/query, est ce que tu peux profiter de l'occasion pour supprimer l'ancien fichier API_CRI_Asynchrone_v1.3.0.yaml également stp ?
Merci encore.
| - name: id | ||
| in: path | ||
| - name: accessId | ||
| in: query |
There was a problem hiding this comment.
Ah, je n'avais pas fait attention à ça (comme quoi le difff, ça sert :-)).
Pourquoi être passé en query plutôt que path ? La ressource est moins claire à la consultation non ?
Cf :
There was a problem hiding this comment.
Je reviens à la charge sur le sujet car en plus de passer de path à query, vous supprimez les différentes ressources et créer un seul point d'entrée permettant les différentes consultations sur les différents identifiants en même temps.
Personnellement, je suis foncièrement contre. Nous retombons dans les galères des autres WS où le consommateur du service / API peut envoyer plusieurs identifiants dans différents champs, qui potentiellement ne sont pas cohérents les uns avec les autres (une prestation qui n'a rien à voir avec la commande par exemple)... et le fournisseur de service doit gérer tout cela :-(
Notre volonté au départ était bien de fiabiliser ces échanges, et de ne pas rentrer dans de la normalisation inutile via document word (comme les différentes ressources permettent d'être discriminant)... donc N identifiants, N endpoints, ou alors une seule ressource, requêtable via un objet gérant le polymorphisme, avec N implémentations de cet objet ne portant chacune qu'un seul identifiant (mais du coup ça se complique)... Sinon tout le monde ira de sa sauce encore une fois.
Si je ne suis pas clair, on peut s'appeler @mrongier .
Un avis @NicolasD-Altitude @AltitudeAntoineS ?
There was a problem hiding this comment.
Bonjour @aminvielledebat ,
Merci pour ton retour. Pour moi c'est très clair, et c'est effectivement le défaut de la solution. De notre coté, on n'avait pas identifier comme un problème complexe le fait de gérer les multi input (on en accepte qu'un à la fois).
Avec la version 1.1.0, d'un point de vu OC, nous allons devoir mettre en oeuvre différentes ressources, qui, pour des besoins internes OC, existent déjà et ne sont pas toujours portées par les mêmes systèmes techniques. Cela va nous imposer de développer une couche d’unification en front avec les OI. C’était l'origine de notre proposition.
Manuel
There was a problem hiding this comment.
Hello Manuel,
Ce n'est clairement pas un sujet complexe à implémenter, mais qui peut vite le devenir fonctionnellement si l'info n'est pas clairement explicitée dans un doc adhoc. (Sinon rien n’empêcherait un OC d'imposer la fourniture de la ref interne et de la ref prestation, ou encore d'un autre identifiant par ex).
Personnellement, je suis plutôt adepte des outils qui imposent des choix d'implémentation sans avoir à se poser la question d'un potentiel doc ad'hoc. Pas de question, pas de souci :-)
Un avis côté Altitude @NicolasD-Altitude ?
