Es ist ein Schritt, der sich bereits seit längerem abzeichnete. Daher möchte ich die API nicht kommentarlos abschalten, sondern auch meine Gründe dazu erklären.
Angefangen habe ich mit der API als Schüler im April 2014. Damals vorallem, um die Daten selbst für eigene Anwendungen zu verwenden. Da ich die Daten anfangs noch von Schulferien.org bezog, war es dabei kein Mehraufwand auch andere Bundesländer zu unterstützen und habe die API daher für ganz Deutschland öffentlich bereitgestellt.
In dieser Zeit erhielt ich gelegentlich Anfragen von Firmen, die sich bei mir erkundigten, ob sie die API verwenden dürfen. Sofern sinnvolles Caching verwendet wurde, habe ich dazu auch nie nein gesagt. Da ich einen Überblick über meine Nutzer haben wollte, habe ich meine Richtlinien dahingehend verschärft, dass ich Firmen aufforderte mich vor der Nutzung über den geplanten Einsatzzweck zu informieren. Teilweise wurde dies getan, teilweise aber auch gekonnt ignoriert.
Im Sommer 2017 kam für mich nach dem Abitur erstmals die Frage auf, wie ich mit der API weiter verfahren würde. Ich selbst brauchte die Daten nicht mehr, somit bedeutete die weitere Pflege der Daten für mich einen erheblichen Aufwand. Dazu kam, dass Schulferien.org inzwischen deutlich gemacht hatte, dass sie einer Verwendung der Daten zu diesem Zweck nicht zustimmten und ich die Daten händisch pflegen musste. Gerade aufgrund der vielen Firmen, die die API inzwischen einsetzten schien es mir aber sinnvoll, die API nicht einzustellen, sondern gegen einen geringen monatlichen Betrag anzubieten. Das bedeutet aber ebenfalls einen hohen Aufwand, da nun API Keys verwaltet, Aufrufe gezählt und Rechnungen erstellt werden müssten.
Ein großer Teil der dafür notwendigen Software ist inwischen fertig, darunter auch eine verbesserte API Version, die erweiterte Parameter entgegen nimmt. Die gesamte API wird seit Sommer 2017 von einer gunicorn Anwendung als Python3 Webservice betrieben und versteckt sich zur Übersetzung der alten Parameter ohne API Key hinter einem (aus historischen Gründen hinter drei) Reverse Proxies. Prinzipiell ist damit ein großer Teil der Software fertig, zur Implementierung eines Kundenportals fehlte mir dann aber die Zeit. Gleichzeitig betreibe ich seitdem jedoch einen vHost, dessen einziger Zweck es ist, diese Applikation zu hosten und damit zurzeit nur Kosten verursacht.
An dieser Stelle möchte ich aber auch auf meine Nutzer eingehen. Darunter waren wirklich nette Leute, die mir ihre Pläne beschrieben haben und die auch eine Nutzungserlaubnis erhalten haben. Leider waren auch Leute dabei, bei denen ich die Beantwortung der Anfrage vergessen habe. Um dies zukünftig zu verhindern, hatte ich bereits ein Ticket System installiert.
Dann gab es aber die Art von Nutzern, die die API ohne zu fragen auf größeren Seiten einsetzten. Darunter auch zwei Reiseveranstalter, einer davon sogar im Produktivsystem. Der Andere nur im Entwicklungssystem. Sieht man sich heute die verwendeten Daten an, wird meine API dort im Produktivsystem immerhin gecached, aber weiterhin ohne Erlaubnis eingesetzt. Gerade bei einem derartigen Einsatz sehe ich jedoch große Probleme, garantiere ich die Korrektheit und insbesondere Aktualität der Daten doch nicht. Bucht ein Kunde nun seinen Urlaub nach falschen Feriendaten, führt dies zwangsläufig zu einer Haftungsfrage. Dazu kommt die Frage nach dem Datenschutz der Kunden und die Integrität der Internetseite. Immerhin wäre durch das Einschleusen fehlerhafter Daten ein Cross-Site Scripting Angriff unter bestimmten Umständen denkbar.
Die Krönung möchte ich aber auch niemandem vorenthalten. Im letzten Sommer fragte ein Nutzer bei mir an, ob er meine API nutzen dürfe. Ich willigte ein und teilte ihm gleichzeitig mit, dass ich wahrscheinlich in absehbarer Zeit auf ein kostenpflichtiges Modell umschwenken werde. Offenbar landete meine Antwort seinerseits dann jedoch im Spam, sodass er sich an einem Freitag gegen Abend gezwungen sah, mich anzurufen. In einem Nebensatz sagte er dann sowas, wie “eigentlich beziehst du die Daten ja auch nur von Schulferien.org”. Ich wies ihn auf die Email hin, die ich im bereits geschrieben hatte, er entschuldigte sich für die Störung und antwortete mir etwas später auf meine Nachricht. Er lehnte mit der Begründung ab, dass er die Daten auch einfach selber von Schulferien.org parsen könne und somit mein Dienst für ihn nicht erforderlich sei. Soweit, so gut. Aber muss man dann wirklich anrufen, anstatt es schnell selbst zu implementieren? Zumal meine Daten zu diesem Zeitpunkt bereits händisch verwaltet wurden und das alte Format “$Ferienname $Bundeland” nur aus Kompatitbilitätsgründen verwendet wurde.
Mittlerweile beschäftige ich mich zu einem großen Teil mit IT Sicherheit. Dies führte auch zu meinem aktuellen Job, sodass für mich die Kommerzialisierung der API in den Hintergrund gerückt ist. Der Zeitaufwand die API aktuell zu halten und der Kostenaufwand den vHost zu betreiben steht für mich daher in keinem Verhältnis zum Nutzen. Letztere ließen sich zwar durch einen Umzug auf einen aktuellen Server verringern, jedoch bleibt der Aufwand und die dreiste Nutzung ohne Erlaubnis. Daher habe ich mich nach längerer Überlegung dazu entschieden die API vollständig, also auch ohne einen kostenpflichtigen Ersatz, einzustellen.
Der vHost läuft noch bis zum 01.06.2019. Innerhalb dieser Zeit werde ich den Dienst auf meinen aktuellen Server umziehen und damit die Kosten für mich senken. Den Betrieb der API werde ich zum 01.01.2020 einstellen. Es bleibt also noch etwas mehr als ein Jahr für alle Nutzer auf eine alternative Schnittstelle zu migrieren.
Ich möchte mich bei allen Nutzern für ihr Vertrauen bedanken. Mein Dank gilt dabei insbesondere den ehrlichen Nutzern, die vor dem Einsatz der Schnittstelle bei mir angefragt haben. Bei allen Nutzern, bei denen ich die Beantwortung ihrer Anfrage versäumt habe, möchte ich mich zudem entschuldigen.
Und jetzt?
Was 2014 noch selten war, gibt es inzwischen in mehrfacher Ausführung. Es gibt also durchaus Alternativen zu meiner API, von denen ich einige unten verlinkt habe:
- https://www.ferien-api.de/
- https://ipty.de/feiertag/
- https://www.mehr-schulferien.de/developers