New format for train departures and journeys

[HerrLevin]

Is your feature request related to a problem? Please describe.
We're currently just forwarding the resultset of a db-rest v5 request to the api. This way we (and our api consumers) are completely dependend on their changes.

Describe the solution you'd like
A custom format, mapping the results of db-rest (and possible future data providers) to a specific format (version) controlled by us. That way we are able to produce reliable results without any concern of the underlying data structure.

Additional context
https://github.com/public-transport/friendly-public-transport-format

[HerrLevin]

@marhei @jheubuch @bendix-dev Ihr seid diejenigen, die die API am stärksten konsumieren. Hier ist euer Input gefragt.

Derzeit reichen wir DB-Rest Antworten 1:1 weiter, ohne etwas daran zu ändern. Das bringt uns das Problem, dass wir DB-Rest nicht upgraden können, ohne euch breaking changes über Nacht zu geben.

Wir würden gerne das FPTF beibehalten, aber idelaerweise als Subset, um die Menge an Daten auf unserer Seite und auch die Menge an Daten, die wir euch übermitteln müssen klein halten können.

Bitte nutzt diese Discussion die kommenden Tage/Wochen, um hier einmal eure absolut notwendigen Schema-Bestandteile sowie die komplett zu vernachlässigenden aufzuschreiben. (Natürlich nur auf die Abfahrten und die Stopovers bezogen)

(bspw: products für die Bahnhöfe sind imho nicht wirklich notwendig. Wir speichern/cachen das nicht und zukunftssicher ist das auch nicht, da wir nicht auf ewig mit HAFAS arbeiten möchten und uns andere APIS ebensowas nicht raus geben.)

[weiland]

Schon mal +1 für die v6 und FPTF. Was Daten angeht, haben wir uns an der API orientiert und alle existierenden Felder eingebaut, von denen wir aber nicht alle verwenden und die nächsten Tage mal alles dokumentieren werden.
Ein Vorschlag für eine Migration wäre irgnendeine Art von Versionierung der API oder des Enpoints, sofern die Endpoints gleichbleiben.

[HerrLevin]

Eine Idee für eine "Versionierung" während der Migration wäre, dass ihr derzeit schon mal einen forceDBRestResponse=true Query Parameter mitgeben könntet. Das wird aktuell einfach fallen gelassen, aber kann dann sinnvoll von uns verarbeitet werden.

Ist zwar keine echte Versionierung, aber offiziell ist die API ja auch noch experimental und für ne Migration sollte das glaube passen. 🫣
(Außer ihr habt da vielleicht ne bessere Idee für)

[bendix-dev]

Hier sind alle Sachen, die ich auf jeden Fall brauche:

Departures:

• meta
  • times: komplett
  • station: name

Departure:

• tripId, when, plannedWhen, delay, direction, cancelled
• line: name, fahrtNr, product, id, operator: id, name
• station: id

Trip:

• category, lineName, number, journeyNumber
• destination: id, name

Stopover:

• id, name, arrival, arrivalPlanned, arrivalReal, departure, departurePlanned, departureReal, isArrivalDelayed, isDepartureDelayed, cancelled
• nur zur Bestimmung ob es ne Abfahrtszeit gibt: arrivalPlatformPlanned, departurePlatformPlanned, platform