Proposition d'ouverture open-data SIRI via un proxy SIRI simplifié

[thbar]

Suite aux différents échanges sur les mois passés, et pour répondre aux difficultés (temporaires ou pas) d'une partie des producteurs en tout cas, j'ai fini par identifier un chemin simplifié (en restreignant les hypothèses) pour faciliter un début d'ouverture SIRI.

Tant que les producteurs peuvent ouvrir en toute autonomie, il faut aller dans ce sens, mais on voit que cela pose des difficultés variées à différents producteurs.

Les difficultés sont classiquement de plusieurs ordres pour les producteurs:

• Je souhaite protéger mon système interne pour ne pas perturber mes opérations
• Je ne connais pas la charge potentiellement générée par une ouverture open-data
• Je ne dispose pas d'un système permettant de bloquer un utilisateur qui dépasserait des limites d'usage
• Je ne dispose pas d'assez de credentials (requestor_ref et/ou je ne dispose pas d'un système de gestion de clés assez souple (ou pas du tout)

Ma proposition est de simplifier fortement le design pour commencer, afin de permettre une première ouverture, partielle, mais disponible rapidement.

Les simplifications que je propose pour commencer sont les suivantes:

• pas de gestion d'abonnement : l'abonnement est préférable, mais les nouveaux utilisateurs trouveront le request/response plus simple à appréhender pour commencer, et on souhaite faciliter ce point
• services restreints: je propose de ne supporter que StopMonitoring (courant et pratique pour obtenir une situation), et en optionnel StopPointsDiscovery, qui si il est présent, permet d'obtenir facilement la liste des arrêts, dont les identifiants sont utiles pour créer une requête StopMonitoring. On pourra envisager plus tard d'ouvrir d'autres services, et ce type de déploiement graduel a déjà été vu dans certains documents.
• Utilisation d'un seul et unique requestor_ref pour commencer, fourni par le producteur. Ce requestor_ref restera privé, ainsi que l'adresse du serveur du producteur.
• Pour le public, il y aura un requestor_ref unique et identique du type transport-open-data, disponible publiquement pour faire de l'open-data en "self service"
• Le proxy PAN intègrera un "rate limiter" pour protéger le serveur du producteur, sur la base d'une fréquence autorisée, et retournera un code d'erreur HTTP 429 (Too Many Requests) avec un message clair en cas de dépassement
• La configuration aura la forme suivante:

- identifier: siri-xyz
  target_url: https://producteur-siri
  requestor_refs:
    - external: transport-open-data
      internal: 1981748BJABERABER
      rate_limit: "1 request per second" 

Les avantages d'une implémentation suivant ces simplifications sont les suivants:

• On dispose d'un "vrai open data" (pick and go, en toute autonomie)
• Le PAN aide à l'ouverture de données déjà existantes mais pour lesquelles il existe des points de friction technique ou organisationnelle qui prendront du temps à régler (voire, qui sont difficilement réglables)
• Ca va aider à faire une première ouverture SIRI tout court
• Protection des producteurs contre les effets de charge
• On évite d'avoir N requestor_ref à gérer pour l'instant, mais on garde la possibilité d'aller vers cela si et quand c'est pertinent plus tard (ce qui sera probablement le cas)
• On facilite la mise en place d'un système de validation par le PAN (car on disposera du requestor_ref et d'un accès public) pour les données SIRI
• Le système est peu compliqué à implémenter et constitue plutôt une évolution du proxy existant qu'un nouveau bloc
• Des métriques seront productibles facilement (infrastructure existante)
• Le design est simple (proxy, pas de concentrateur, code maison déjà identifié)
• Aide à la conformité juridique, quoique partielle (puisque seuls une partie des services seront disponibles) pour les producteurs
• Permet à des réutilisateurs potentiels de commencer à réutiliser la donnée et à découvrir le format
• Facilite la communication technique sur ce format
• Ouvre la voie à des services de conversion vers du SIRI Lite pour ouvrir plus facilement

Voilà - j'ai mis un peu de temps à arriver à trouver la bonne combinaison de simplification, je trouve que c'est faisable et pas très compliqué, avec une bonne plus-value.

[Miryad3108]

Ma remarque ne porte pas sur les services "les plus importants"/"pertinents" à diffuser dans le SIRI mais plutôt sur celles que peuvent fournir les SAEIV avec lesquels j'ai échangé. J'avais envoyé un mail les deux dernières semaines aux SAEIV avec lesquels on échange pour l'ouverture des données SIRI (Navocap, Pysae avec la solution de Lumiplan, Hanover ont répondu) et pour l'instant, les deux informations en commun entre tous ces SAEIV sont :

• StopMonitoring
• GeneralMessage

Pysae (solution Lumiplan), ne peut pas fournir de StopPointsDiscovery pour l'instant (mais c'est optionnel dans ta proposition). Les deux autres peuvent fournir ce service.

[thbar]

Remplacé par:

• https://github.com/etalab/transport-site/issues/2817