Diese API ist nicht die offizielle EFA-Webservice-API unter https://v4-api.efa.de/, sondern diejenige, die von der Webseite selbst verwendet wird – sie besitzt eine deutlich bessere Detailtiefe und unterstützt statt ausschließlichen XML-Output auch jenen in JSON.
Die offizielle EFA-API ist zwar gut und ausführlich dokumentiert, liefert jedoch nur XML-Antworten und ist hinsichtlich der Detailtiefe der Daten ungenau. Nachdem ich mich mehrere Monate mit der offiziellen API - gequält durch den XML-Output - habe ich mich nach einer Alternative umgeschaut.
Beim Blick ins Netzwerkprotokoll auf efa.de fiel mir auf, dass die Webseite eine andere, interne API (folgend einfach "IntAPI" genannt) nutzt.
Ziel dieses Projekts ist es, die IntAPI zugänglicher und nachvollziehbar zu machen, da gute und öffentliche ÖP(N)V-APIs bekanntlicherweise eher Mangelware sind.
| Aspekt | Offizielle API | IntAPI |
|---|---|---|
| Format | XML | wahlweise JSON oder XML in verschiedenen Arten |
| Authentifizierung | Beantragung eines Zugangs-Tokens | frei zugänglich |
| Dokumentation | Offiziell | nur inoffiziell - hier und von einigen unvollständigen Dokus von VU/VV |
| Anfragelimit | 10000 pro Tag pro Zugang | keine Beschränkung / unbekannt |
| Detailtiefe der Requests | mittel lt. Doku zwar hoch, mehrere funktionieren allerdings nicht |
hoch viele exklusive Parameter im Vergleich |
| Detailtiefe der Responses | mittel, wenige Endpunkte | sehr hoch, teilw. sehr spezifische Endpunkte |
| Modularität | nur für Daten von efa.de | universell auf jegliche EFA-Instanzen anwendbar |
Abgesehen von efa.de lassen sich auch andere EFA-Dienste auf die Dokumentation anwenden. Damit lassen sich für bestimmte Gebiete genauere Daten wie Echtzeitdaten oder Störungsmeldungen anzeigen.
Achtung: Im Grundsatz lässt sich die Dokumentation auf alle Dienste anwenden. Allerdings ergeben sich in einigen Datenstrukturen durchaus weitere Properties, die ich noch nach und nach dokumentiere.
| Dienst-ID | URL | Abdeckung Fahrplandaten | Abdeckung Echtzeitdaten & Störungsmeldungen | Einbindung in Dokumentation |
|---|---|---|---|---|
| A | https://efa.de/efa/ |
Deutschland | Stadt+Region Hannover, Hildesheim, Braunschweig, Hameln | |
| DE-VRR | https://www.vrr.de/vrr-efa/https://efa.vrr.de/standard/ |
... | ... | |
| DE-BWS | https://www.bwegt.de/bwegt-efa/https://www.efa-bw.de/nvbw3L/ |
... | ... | |
| AT-LI | https://www.linzag.at/static/https://www.linzag.at/linz2/ |
... | ... | |
| AU-NSW | https://transportnsw.info/web/ |
... | ... | |
| DE-BY | https://mobile.defas-fgi.de/beg/ |
... | ... | |
| DE-VRN | https://mandanten.vrn.de/takt2/ |
... | ... | |
| DE-VGN | https://efa.vgn.de/vgn/ |
... | ... | |
| IT-BZ | https://mobility.api.opendatahub.com/v2/ |
... | ... | |
| DE-VVO | https://efa.vvo-online.de/VMSSL3/ |
... | ... |
In der Dokumentation ist stets der Endpunkt der allgemeinen IntAPI von efa.de angegeben, kann aber 1:1 durch eine der o.g. Alternativen ersetzt werden.
Folgende Dienste wurden bereits kontrolliert und besitzen die selben Daten wie oder eine Teilmenge der Daten der schon o.g. Dienste. Die Beurteilung dieser Doppelungen findet anhand einer Abfrage von XML_ADDINFO_REQUEST und anschließendem Vergleich der ausgegebenen Meldungen statt, da sich diese erfahrungsgemäß nur auf das abgedeckte Verkehrsgebiet beschränken. Die doppelten Dienste können zwar genutzt werden, aufgrund keiner weiteren Prüfung kann es hier jedoch noch zu Unterschieden kommen oder geringeren Datenmengen kommen. Aus dem Grunde empfehle ich einfach die Nutzung der obigen Dienste, die eh ja nicht weniger als ihre Duplikate abdecken.
| URL | (Teil-)Übereinstimmung mit Dienst |
|---|---|
https://bsvg.efa.de/vrbstd/ (BSVG) |
A |
https://efa.projektionisten.eu/efaws2/default/ (RVHI) |
A |
https://www.westfalenfahrplan.de/nwl-efa/ (WT) |
DE-VRR |
https://www.naldo.de/_assets/012ccdbd1331184d82aa9387f0ed2f73/efa/ (naldo) |
DE-BWS |
https://www3.vvs.de/mngvvs/ (VVS) |
DE-BWS |
https://www.kvv.de/tunnelEfaDirect.php?action= (KVV) |
DE-BWS |
https://www.fahrplanauskunft-mv.de/vmv-efa/ (MV)Mecklenburg-Vorpommern und Banden-Würrtemberg nutzen eine gemeinsame EFA-Instanz |
DE-BWS |
https://www.vrt-info.de/fahrplanauskunft/ (VRT) |
DE-VRN |
https://vogtlandauskunft.de/vvv2/ (VVV) |
DE-VVO |
http://efa.vvo-online.de:8080/std3/trias/ (VVO) |
DE-VVO |
https://efa.mvv-muenchen.de/mobile/ (MVV)Keine Echtzeitdaten, teilweise falsche Datenbasis |
DE-BY |
Falls du...
- fehlende Parameter oder Felder herausfindest,
- einen weiteren EFA-Dienst entdeckst,
- weitere Abweichungen der bekannten Dienste aufdeckst (ggf. auf Version achten),
- ...
Ich oder dieses Projekt steht in keiner Verbindung zu den Betreibern von efa.de oder anderen Unternehmen/Verbünden, die EFA einsetzen.
Die hier dokumentierte Schnittstelle ist nicht offiziell dokumentiert oder freigegeben und kann sich theoretisch jederzeit ändern. Die Informationen wurden ausschließlich durch die Analyse öffentlich zugänglicher Netzwerkrequests der Webseiten gewonnen.
Nutzung auf eigene Verantwortung.
- Dokumentation bezieht sich auf
rapidJSON-Format: Die gesamte Dokumentation wurde auf Basis vonrapidJSON-Outputs erstellt und wird auch auf Basis dieser geplegt - inbesondere die nicht-verarbeiten Ausgabeformate haben bedeutend andere Response-Datenstrukturen, u.U. istrapidXMLdavon auch betroffen. Die Wahl fiel auf JSON im allgemeinen, da dieses Format im Gegensatz zu XML moderner ist und auch höher typisiert (eindeutiger) ist. - Gruppierung von Request-Parametern: Insbesondere bei Anfragen mit vielen Parametern habe ich Hilfsparameter (z.B. "--- ALLGEMEIN ---") eingefügt, um die Parameter etwas zu gruppieren und für etwas mehr Übersicht zu sorgen. Diese können für Tests in der Apidog-Oberfläche problemlos mitgesendet werden, das stört die Dienste nicht.
- Parameterdoppelungen: Einige Request-Parameter doppeln sich in ihrer Funktion (z.B. Zeitauswahl: auch Parameter zum separeten Setzen von Jahr, Monat und Tag verfügbar). Der Übersichtlichkeit halber wurden diese Doppelungen nicht mit in die Dokumentation aufgenommen. Die aufgenommen Parameter erfüllen (mindestens) alle Funktionen, die die nicht erwähnten Parameter auch erfüllen.
- Parameter für UI-Ausgaben: Parameter, die sich auf die Ausgabe eines GUI beziehen (z.B.
itdLPxx_paramName), werden in der Dokumentation nicht aufgelistet.