Skip to content

Routing: Neue API für RTD bereitstellen

User Story

Nutzende von FIT-Connect erwarten, dass das Routing auf Basis aktuell gültiger Daten in der Test-Umgebung erfolgt, um FIT-Connect korrekt nutzen zu können.

Warum

Aus #2396 (closed) ergibt sich eine Fehleranfälligkeit und Lücke bei der Verwendung von PVOG, DVDV und FIT-Connect in der Test-Umgebung.

Es sollen neue API-Endpunkte bereitgestellt werden, um das Routing auf Basis aktuell gültiger Daten durchzuführen.

Der RTD muss die DestinationID und DestinationSignature erhalten. Falls die Daten für eine Destination nicht anderweitig verfügbar sind, kann als Fallback der ZSD aufgerufen werden, um die Daten zu erhalten.

Neuer Pfad in der Internal-API - /internal/routing/[...]

/search

  • Parameter: ARS (amtlicher Regionalschlüssel), Leistungsschlüssel / LeiKa-ID, Limit+Offset für Pagination. Um Konsistent mit den anderen Schnittstellen zu bleiben wird der ARS hierbei mit 'DE' Prefix gefordert. Dies deckt sich mit #2392 (comment 187865)
  • Rückgabe: Paginierte Liste von DestinationID, destinationParameter, destinationParameterSignature und DestinationSignature, wenn keine Destinations gefunden werden -> leere Liste, Ziel ist es möglichst alle relevanten Informationen für die Routing-Dienst zur Verfügung zu stellen (siehe Schema Definition von https://docs.fitko.de/fit-connect/docs/apis/routing-api/#get-/routes)
  • Für den ARS wird eine Prefix-Suche unterstützt um die Hierarchie dieser Schlüssel abzubilden
  • dieser Endpunkt wird vom ZSD in allen Umgebungen ausgeliefert, jedoch vom Routing-Dienst via Konfiguration nur in der TEST Umgebung genutzt

Links, Hinweise, Bemerkungen

Akzeptanzkriterien

  1. ZSD erzeugt DestinationSignature
  2. Absicherung des Zugriffs über eigenen Scope für RTD - "routing-search"
  3. ZSD stellt Endpunkt in der internal API, um nach DestinationIDs+Signature zu suchen
  4. ZSD bietet eine API für den RTD mit OAuth an, über die DestinationID, DestinationSignature, DestinationParameter und DestinationParameterSignature von zu LeiKa-ID und ARS passenden aktiven Zustellpunkten zurückgegeben werden. Die dafür benötigte DestinationSignature wird in Vorgriff zu #2379 vom ZSD generiert.

Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)

Edited by Fabian Sudau