APIs selbst erstellen
Daten frisch serviert
Veröffentlicht in Ausgabe 02/2026 - PRAXIS
Das Entwickeln eines API gestaltet sich einfacher als bei einer Webseite, da es keine grafische Formatierung oder sonstigen Schnickschnack gibt – CSS und JavaScript fallen weg. Die gelieferten Daten müssen sich jedoch strikt an das vereinbarte Schema halten, damit der Client sie verarbeiten kann. Nachträgliche Änderungen an der Syntax sind tabu. Wir stellen in diesem Workshop das Entstehen eines APIs im REST-Design vor. Als Beispiel dient uns ein einfacher Webserver und die Programmiersprachen Bash und Perl – wir verzichten auf Webframeworks. Als Einstieg vertiefen wir zunächst einige Vokabeln aus der API-Sprache.
So funktioniert ein API
Jede Ressource eines API ist über einen "Uniform Resource Locator" (URL) erreichbar, umgangssprachlich auch als Webadresse bezeichnet. Eine beispielhafte URL lautet "http://example.net/api?q=text". Besonders wichtig sind dabei der Pfad ("/api") und der Parameter "q=text". Der Pfad heißt in vielen Dokumentationen "Endpunkt" und entspricht dem Befehl, den der Client ausführen möchte. Dazu kann der Client eine Wunschliste als Parameter übergeben, die der API-Server zur Abarbeitung benötigt. Das HTTP-Protokoll kennt verschiedene Verben, die ein Client an den Server übergeben kann. Dazu gehören GET, HEAD, POST, PUT, DELETE und etwa 30 weitere. Von diesen sind rund zehn in der Praxis geläufig, wir beschränken uns im Workshop auf GET und POST.
Über einen Zahlencode teilt der Webserver dem Client mit, ob die Anfrage erfolgreich war oder ob ein Problem besteht. Die Codes sind stets dreistellig: Die Zahlen von 200 bis 299 sind reserviert für "in Ordnung", 400er-Statuscodes stehen für ein clientseitiges Problem und eine führende Fünf signalisiert ein Problem beim Server. Nach dieser Definition verursacht also der Client den bekannten 404-Fehler "Not Found", da dieser einen toten Link aufrufen will. Welche Statuscodes für das API angemessen sind, legt die Spezifikation fest. Dieser Workshop nutzt lediglich den Code 200 für erfolgreiche Abfragen, während 500 für ein serverseitiges Problem steht. In der Praxis lässt sich aus über 30 verschiedenen Codes im 400er-Bereich wählen, um seinen Client abzustrafen, oder einen der zehn 500er-Codes, um seinen Fehler zuzugeben.
Das Entwickeln eines API gestaltet sich einfacher als bei einer Webseite, da es keine grafische Formatierung oder sonstigen Schnickschnack gibt – CSS und JavaScript fallen weg. Die gelieferten Daten müssen sich jedoch strikt an das vereinbarte Schema halten, damit der Client sie verarbeiten kann. Nachträgliche Änderungen an der Syntax sind tabu. Wir stellen in diesem Workshop das Entstehen eines APIs im REST-Design vor. Als Beispiel dient uns ein einfacher Webserver und die Programmiersprachen Bash und Perl – wir verzichten auf Webframeworks. Als Einstieg vertiefen wir zunächst einige Vokabeln aus der API-Sprache.
So funktioniert ein API
Jede Ressource eines API ist über einen "Uniform Resource Locator" (URL) erreichbar, umgangssprachlich auch als Webadresse bezeichnet. Eine beispielhafte URL lautet "http://example.net/api?q=text". Besonders wichtig sind dabei der Pfad ("/api") und der Parameter "q=text". Der Pfad heißt in vielen Dokumentationen "Endpunkt" und entspricht dem Befehl, den der Client ausführen möchte. Dazu kann der Client eine Wunschliste als Parameter übergeben, die der API-Server zur Abarbeitung benötigt. Das HTTP-Protokoll kennt verschiedene Verben, die ein Client an den Server übergeben kann. Dazu gehören GET, HEAD, POST, PUT, DELETE und etwa 30 weitere. Von diesen sind rund zehn in der Praxis geläufig, wir beschränken uns im Workshop auf GET und POST.
Über einen Zahlencode teilt der Webserver dem Client mit, ob die Anfrage erfolgreich war oder ob ein Problem besteht. Die Codes sind stets dreistellig: Die Zahlen von 200 bis 299 sind reserviert für "in Ordnung", 400er-Statuscodes stehen für ein clientseitiges Problem und eine führende Fünf signalisiert ein Problem beim Server. Nach dieser Definition verursacht also der Client den bekannten 404-Fehler "Not Found", da dieser einen toten Link aufrufen will. Welche Statuscodes für das API angemessen sind, legt die Spezifikation fest. Dieser Workshop nutzt lediglich den Code 200 für erfolgreiche Abfragen, während 500 für ein serverseitiges Problem steht. In der Praxis lässt sich aus über 30 verschiedenen Codes im 400er-Bereich wählen, um seinen Client abzustrafen, oder einen der zehn 500er-Codes, um seinen Fehler zuzugeben.
Infrastruktur aufsetzen
Wir stellen in diesem Workshop Funktion vor Design und verzichten auf Themen wie Sicherheit, Lastverteilung oder Ausfallschutz. Zentral sind für uns einfache Komponenten, die sich zum Lernen eignen. Daher nutzen wir den Webserver Caddy, der mit wenigen Konfigurationszeilen einen API-Server bereitstellt. Bei der Programmiersprache eignet sich Bash, auch wenn Python, Go und Java die Beliebtheitslisten anführen.
Caddy erlangt die Fähigkeit, eigene Skripte auszuführen, durch das CGI-Plug-in [1]. Fertige Executables inklusive des gewünschten Plug-ins bietet Caddy unter [2] zum Download an. Dort wählen Sie "Linux amd64" als Plattform aus und suchen nach dem Plug-in "caddy-cgi". Der Downloadbutton rechts oben bringt das gewünschte Executable "caddy_linux_amd64_custom" auf den lokalen Rechner. Benennen Sie die Datei "caddy" und machen Sie sie mit
chmod +x ausführbar. Zusätzlich benötigen wir noch einige Helferlein, die allesamt per Paketmanager auf den eigenen Linux-Rechner kommen, hier am Beispiel von Debian:apt install jc at geoip-bin
Damit ist die API-Infrastruktur bereit für den ersten Programmcode.
Das API einsetzen
Als erstes Beispiel soll der API-Webserver beim Aufrufen der Adresse "http://localhost/temp" die aktuelle Temperatur ausgeben. Der Temperaturwert liegt dabei nicht in irgendeiner Textdatei, sondern wird dynamisch per Skript ermittelt. Unser Webserver erhält seine Anweisungen aus dem Caddyfile. Erstellen Sie also eine neue Datei namens "Caddyfile" und geben ihr folgenden Inhalt:
{
order cgi before respond
}
:80 {
cgi /temp temperature.sh
}
Beim Zugriff auf den Pfad "/temp" soll Caddy das Skript "temperature.sh" aufrufen und dessen Ausgabe per HTTP an den Client liefern. Im einfachsten Fall generiert das Skript per echo- oder printf-Anweisung einen Zahlenwert wie beispielsweise 22,57. Das Skript nimmt folgende Form an:
#!/bin/bash
printf "Content-type: text/plain\n\n"
printf "22.57"
Der Content-Type ist für den Client wichtig, und ohne diese Angabe liefert Caddy nichts aus. Zu guter Letzt muss das Skript per
chmod +x temperature.sh ausführbar sein. Sind alle Bauteile bereit, startet caddy run unsere Beispielumgebung. Ein Client kann nun das API nutzen, um die Temperatur anzufragen. Dies ist per Webbrowser oder auf der Kommandozeile mit dem Befehl curl http://<server>/temp möglich. Wenn keine Firewall den Zugriff verhindert, erscheint sogleich der Temperaturwert im Browser.Doch die erste Freude ist schnell verflogen, denn die ausgelieferte Temperatur ist ein statischer Wert. Wer zufällig ein USB-fähiges Thermometer griffbereit hat, kann einen realistischen Messwert per API bereitstellen. Das temperhum-Kommando liefert sowohl die aktuelle Umgebungstemperatur als auch die Luftfeuchte. Unser Skript muss die Temperatur aus den Messwerten herausfischen und per "printf"-Befehl präsentieren. Das Skript erweitert sich zu:
#!/bin/bash
temperature=$(temperhum | awk '{print $1}')
printf "Content-type: text/plain\n\n"
printf "temperature: ${temperature} C\n"
Damit hat das API den Demostatus verlassen und liefert nun realistische Temperaturen an neugierige Clients. Aber nur im Textformat, was im modernen Internet ungewöhnlich ist.
Ausgabe in JSON umwandeln
Ausgaben im Textformat lassen sich von der aufrufenden Software nur schwer verarbeiten. Daher haben sich für APIs andere Formate durchgesetzt: JavaScript Object Notation (JSON) und Yet Another Markup Language (YAML). Beide Formate sind nicht nur maschinenlesbar, sondern auch ohne Vorkenntnisse gut erkennbar. Nun soll also das Temperatur-API seine Werte im JSON-Format präsentieren:
#!/bin/bash
temperature=$(temperhum | awk '{print $1}')
printf "Content-type: application/json\n\n"
echo '{"temperature":"'$temperature'","unit":"celsius"}'
Ein Zugriff auf den Temperatur-Endpunkt liefert nun den Celsius-Wert formatiert in JSON. Der Zusatz "jq" macht die Ausgabe optisch ansprechender, ohne dass sich der Inhalt verändert:
curl --silent http://localhost/temp | jq
{
"temperature": "19.22",
"unit": "celsius"
}
Eingaben vom Client einfordern
Als nächstes Beispiel wollen wir einen API-Endpunkt aufsetzen, der eine Eingabe vom Client erwartet. Caddy ruft das hinterlegte Perl-Skript auf und übergibt die Eingabe als Parameter. In diesem Beispiel kommt die Programmiersprache Perl hinzu, um die Gefahr bei fehlender Eingabeprüfung zu demonstrieren – dazu später mehr. Das Caddyfile erhält unterhalb der Temperaturzeile den neuen Eintrag "cgi /geoip/* geoip.pl". Die Neuerung liegt im Jokerzeichen, das am Ende des Pfads eine variable Eingabe erfordert. Das Skript erhält diesen Wert aus der Umgebungsvariablen "PATH_INFO":
#!/usr/bin/perl
print "Content-type: application/json\n\n";
( $ipaddr = $ENV{'PATH_INFO'} ) =~ s!/geoip/!!;
print `geoiplookup $ipaddr | jc --kv`;
Das Skript liefert jetzt nicht mehr in Textform aus, sondern kündigt in Zeile 2 das JSON-Format an. Zeile 3 zieht aus dem Pfad die IP-Adresse heraus und ermittelt daraus in Zeile 4 die Länderinformation. Da der geoiplookup-Befehl kein JSON liefert, muss der Konverter "jc" ran und die Ausgabe API-fähig machen. Ein Client kann jetzt seine IP-Wünsche eingeben und erhält ein Land als Antwort:
curl http://localhost/geoip/191.23.4.1
{"GeoIP Country Edition":"BR, Brazil"}
Da der geoiplookup-Befehl nur IPv4-Adressen akzeptiert, taugt das API offensichtlich nur für solche Adressen. Geo-Funktionen für IPv6 benötigen den Befehl "geoiplookup6".
Die Schnittstelle arbeiten lassen
Nun wollen wir erreichen, dass wir nicht nur Informationen aus dem API abrufen, sondern Arbeitsaufträge übergeben. Als Beispiel soll ein Wecker entstehen, den wir mit einem POST-Kommando auf die gewünschte Weckzeit einstellen. Die bislang genutzte GET-Methode liefert die eingestellte Zeit zurück, während sie sich per DELETE-Befehl löschen lässt. Caddy realisiert den neuen Endpunkt durch die zusätzliche Zeile "cgi /wecker wecker.sh". Den kompletten Inhalt des wecker.sh-Skripts zeigt das Listing.
Listing: Wecker-API mit POST-Methode einstellen
#!/bin/bash
function message() {
echo '{"message": "'$1'"}'
}
printf "Content-type: application/json\n\n"
if [ "${REQUEST_METHOD}" == "GET" ] ; then
# Zeige die aktuelle Weckzeit
message "$(atq)"
elif [ "${REQUEST_METHOD}" == "POST" ] ; then
if [[ $(atq) ]]; then
message "Wecker bereits gestellt"
else
if [ -n "$CONTENT_LENGTH" ]; then
read -r -n "$CONTENT_LENGTH" POST_DATA
time=$(echo "${POST_DATA}" | jq
--raw-output .time)
if [ -z ${time+x} ]; then
message "Weckzeit fehlt"
else
if echo "beep" | at -M "${time}" 2>/dev/null ; then
message "Erfolg"
else
message "Fehler"
fi
fi
fi
fi
elif [ "${REQUEST_METHOD}" == "DELETE" ] ; then
id=$(atq | awk '{print $1}')
if atrm "$id"; then
message "Erfolg"
else
message "Fehler"
fi
fi
Derart vorbereitet, lässt sich die Weckzeit per API auf 6:30 Uhr einstellen:
curl --request POST --data '{"time":"6:30"}' \
http://localhost/wecker
curl http://localhost/wecker
{"message": "1 Mon Oct 14 06:30:00 2024 a root"}
Der zweite curl-Aufruf prüft, ob der Wecker die neue Alarmzeit angenommen hat. Soll der Alarm etwa während des Urlaubs stumm sein, löschen Sie diesen per DELETE-Methode:
curl --request DELETE http://localhost/wecker
Welche Endpunkte und welche HTTP-Methoden es in diesem API gibt, sollte in einer Dokumentation stehen – dazu später mehr.
API-Befehle prüfen lassen
So schön und einfach die API-Programmierung bisher aussehen mag, überspringen wir doch mehrere Aspekte, um schnelle Lernerfolge zu erzielen. In der Realität muss der Code hinter den Endpunkten mehrere Prüfungen durchlaufen, bevor er etwas in Gang setzt. So sollte das GeoIP-API eingangs prüfen, ob der Client tatsächlich eine IPv4-Adresse übermittelt. Andernfalls gibt die Schnittstelle einen Fehler zurück, bevor Schlimmeres passiert. Ohne diese Checks könnte der Client beliebige Shell-Kommandos einschleusen und damit den API-Server auskundschaften oder kompromittieren.
Im folgenden Beispiel hängt der Angreifer einen Shell-Befehl an die IP-Adresse an und erhält so Auskunft über den Linux-Kernel des API-Servers:
curl http://localhost/geoip/ "1.1.1.1;uname%20-r"
GeoIP Country Edition: AU, Australia
{"5.14.0-427.40.1.el9_4.x86_64":""}
Das funktioniert, weil das geoip-Skript alles hinter dem Text "/geoip/" als Parameter für den geoiplookup-Befehl nutzt. Das Semikolon beendet das Kommando und startet den nächsten Befehl. Genau hier führt das Skript alles aus, was nach dem Semikolon erscheint. Dazu gehören auch gefährlich Befehle wie "rm" oder "shred". Perl ist in diesem Punkt argloser als Bash, weshalb wir ersteres im Beispiel Perl nutzen. Bash dereferenziert Sonderzeichen und umringt die Argumente korrekt mit einfachen Anführungszeichen, was den Semikolon-Trick verhindert.
Hier müssen Sie beim entwickeln des API unbedingt prüfen, ob die Eingabe gültig und sinnvoll ist. Das ist bei einer IPv4-Adresse noch relativ einfach: Wenn die Eingabe aus vier Zahlen zwischen 0 und 255 besteht, die jeweils durch einen Punkt getrennt sind, dann sind die Daten gültig. IPv6 mit seinen Abkürzungsregeln macht die Validierung komplexer.
Clients authentifizieren
Soll Ihr Interface nicht der ganzen Welt offenstehen, kann Authentifizierung den Zugriff einschränken. Das Konzept funktioniert wie bei Webseiten mit Benutzeranmeldung. Üblicherweise regelt der Webserver oder ein vorgeschaltetes API-Gateway die Anmeldung. Zur Demonstration (und abseits von Best Practices) kümmert sich das Skript selbstständig um die Authentifizierung. Die Möglichkeiten sind vielfältig: Benutzername mit Passwort, API-Schlüssel, JSON-Web-Token oder ein externer Authentifizierungsdienst stehen zur Auswahl. Als Einstiegsbeispiel erwartet die folgende Code-Erweiterung einen API-Schlüssel, den der Client im Header mitsendet:
if [ "${HTTP_X_API_KEY}" = "1234" ] ; then
# hier folgt der weitere Code
else
message "Anmeldung fehlgeschlagen"
fi
Ab sofort kann ein Client das API nur noch nutzen, wenn er den API-Schlüssel kennt und bei jeder Anfrage vorzeigt, so wie hier:
curl --header "x-api-key: 1234" http://api.example.net/wecker
Best Practices
Best Practices sind keine Standards oder Erfolgsgarantien, sondern bewährte Arbeitsweisen. Ein Beispiel ist das detaillierte Regelwerk für die Entwickler von Zalando für RESTful-APIs [3]. Auf diese Empfehlungen können Sie für die Programmierung zurückgreifen, wenn Sie keine konkreten internen Vorgaben haben.
Darüber hinaus haben sich folgende Best Practices bewährt:
- Nutzen Sie JSON als bevorzugtes Format: Jede moderne Programmiersprache kann damit umgehen. Eingabewerte in JSON lassen sich leicht einlesen und als Variablen weiternutzen. Die Ausgabe im JSON-Format hilft dem aufrufenden Programm außerdem, die Werte einzulesen.
- Ändern Sie nicht den Pfad innerhalb des API: Anders als bei der Überarbeitung einer Webseite, die für menschliche Nutzer ohne Dokumentation oder Spezifikation verständlich ist, führt eine Änderung am API bei der Gegenstelle zu Fehlermeldungen.
- Wenn Sie Änderungen erwarten, platzieren Sie eine Versionsnummer in der URL. Das Wecker-API ist dann zum Beispiel unter dem Pfad "/api/v1/wecker" erreichbar. Dieser Tipp ist allerdings umstritten. So sprechen sich die oben verlinkten Zalando-How-tos gegen die Versionsnummer aus und nutzen den Deprecated-Header, um einen Bereich des API abzukündigen.
- In Sachen Sicherheit gelten für den API-Server grundsätzlich dieselben Empfehlungen wie für den Betrieb eines Webservers.
Daneben gilt für alle Eingabeparameter, die das Interface vom Client erhält, das Prinzip "Never trust user input". Wenn das API beispielsweise eine Temperatur als Parameter erwartet, müssen Sie dies validieren. Besteht der Wert aus Zahlen und eventuell einem Komma? Hat die Zahl eine sinnvolle Größe zwischen 10 und 70? Erhält der Eingabewert unerwünschte Zeichen wie beispielsweise einen Backslash, ein Semikolon oder ein Zeilenende? Nur wenn es sich zweifelsfrei um eine Zahl handelt, geht es im Programmcode weiter.
Die bisherigen Beispiele erstellen die JSON-Antworten mit den Funktionen echo oder printf. Bei kurzen Texten ist das Jonglieren mit Hochkommata und geschweiften Klammern noch geradeso zu bewältigen. Sie sollten den JSON-Code nicht von Hand erstellen, sondern eine Bibliothek oder Befehle wie "jq" oder "jc" nutzen, damit die Syntax perfekt sitzt.
Caddy und dessen CGI-Plug-in bieten es zwar nicht an, doch Sie sollten die HTTP-Rückgabewerte nutzen. Wenn eine Operation erfolglos war, ist der Client für einen Hinweis zur Ursachenforschung dankbar. Bei einem 401 "Unauthorized" fehlt offenbar der korrekte API-Schlüssel, bei 404 "Not found" ist in der URL vermutlich ein Tippfehler und wird die POST-Anfrage mit einem 405 "Method Not Allowed" beantwortet, sind wohl nur GET und DELETE erlaubt.
Dokumentation der API-Zugriffe
Schnell gebastelte Bash-Skripte sind eine hervorragende Quelle für undokumentierten Programmcode, der in jedem Audit sofort durchfällt. Eine API-Dokumentation entsteht üblicherweise nicht als Word-Dokument, sondern im Open-API-Format, auch als Swagger bekannt. Wer sich nicht durch die Spezifikation blättern möchte, springt zum Online-Editor [4] und erstellt die Doku anhand der Beispiele.
Für die Arbeit direkt im YAML-Code gibt es grafische Tools wie API-Fiddle oder ApiBldr, die sich um korrekte Syntax kümmern. Die Webseite von OpenAPI sammelt sinnvolle Tools zum Thema, darunter auch mehrere, die die Dokumentation fördern [5].
Mit hurl das API testen
Der schnelle Funktionstest eines API ist mit dem curl-Befehl rasch erledigt. Jedoch prüft das nur einen einzelnen Endpunkt und verrät nichts über den Zustand der anderen. Besser ist ein gründlicher Test mit einem geeigneten Programm wie beispielsweise "hurl". Der Name ist kein Tippfehler, sondern soll auf die Ähnlichkeit mit "curl" hinweisen. Über die hurl-Funktion rufen Sie Webadressen auf und vergleichen die Antworten mit vordefinierten Zuständen. Dazu erwartet der Befehl die Checkliste als Datei, und ein einzelner Check hat folgende Form:
GET http://api.example.net/wecker
HTTP 200
[Asserts]
jsonpath "$.message" exists
Der Aufruf des Wecker-API muss den HTTP-Statuscode 200 liefern und in der JSON-formatierten Antwort den Text "message" enthalten. Beim Demo-API mit drei HTTP-Methoden ist die hurl-Datei noch übersichtlich. Bei einem großen API mit vielen Endpunkten ufert die Checkliste schnell in viel Arbeit aus. Dann profitieren Sie davon, Ihr API als OpenAPI-Spezifikation angelegt zu haben, denn aus der Dokumentation lassen sich die Tests ableiten und automatisiert durchführen.
Bevor Sie alle API-Endpunkte als hurl-Checks abbilden, werfen Sie einen Blick auf das Projekt "openapi-to-hurl" [6]. Der Name ist Programm: Das gleichnamige Kommando erwartet die OpenAPI-Datei und liefert die hurl-Checks. Diese sind zwar vollständig, aber eher als Vorlage nutzbar, da zu jedem Check die erwartete Antwort fehlt.
Mithilfe der OpenAPI-Spezifikation lässt sich auch ein Pentest-Tool füttern, um damit das API auf Schwachstellen abzuklopfen. In Bild 2 liest der "Zed Attack Proxy" [7] die Dokumentation des Wecker-API und ruft gezielt Endpunkte mit absichtlich falschen Parametern auf.
Grenzen unseres API-Codes
Das vorgestellte Caddy-Bash-Konstrukt eignet sich zwar für einen Einstieg in die API-Programmierung, der Schritt zu ernsthaftem API-Code misslingt jedoch aus mehreren Gründen. So kennt das CGI-Plug-in nur die Rückgabewerte 200 für OK und 500 für Nicht-OK. Die vielen Nuancen dazwischen bleiben dem Client und dem Entwickler verborgen.
Wenn ein API-Aufruf viele Parameter erfordert, wird die Variable "QUERY_ STRING" entsprechend lang. Bash muss daraus die Variablen anhand der Trennzeichen rauspicken und sich gleichzeitig noch um die Eingabeprüfung kümmern. Und das eventuell noch bei mehreren HTTP-Methoden wie GET, POST, PUT und DELETE. Das ist zwar machbar, aber es wird kleinteilig und fehleranfällig.
Weder Caddy noch Perl schützen vor dem Semikolon-Trick, sondern nur Sie: Ein seriöses API setzt API-Firewalls oder API-Gateways ein und verschiebt damit Aufgaben wie Authentifizierung, Rate-Limiting und Bot-Schutz aus dem Programmcode heraus. Zuletzt ist ein Bash-API ein seltenes Unikat. Dennoch eignet sich diese Sprache für eine Demonstration, da vermutlich jeder Admin schon das eine oder andere Problem per Bash-Skript gelöst hat und mit der Arbeitsweise vertraut ist.
Fazit
Softwareentwickler werden über die erstellten API-Skripte nur die Nase rümpfen. Dennoch zeigen die Beispiele auf einfachste Weise, wie ein API funktioniert, welche Unterschiede die HTTP-Methoden aussagen und dass es mehr Statusmeldungen gibt als den Fehler 404. Natürlich können Sie die API-Programmierung auch in Rust oder Java lernen, aber einsteigerfreundlich ist das nicht. Für die Einarbeitung und das Verständnis eignen sich Caddy, Bash und etwas Perl. Sobald ein ernsthaftes API in Aussicht steht, muss eine seriöse Sprache her. Die Best Practices in Sachen Sicherheit und Dokumentation gelten allerdings sprachunabhängig.
(jp)
Links
[1] CGI-Plug-in für Caddy: https://it-a.eu/q1p11
[2] Caddy-Downloads: https://it-a.eu/q1p12
[3] Zalando API-Guide: https://it-a.eu/q1p13
[4] Swagger-Editor: https://it-a.eu/q1p14
[5] OpenAPI-Tools: https://it-a.eu/q1p15
[6] OpenAPI in hurl umsetzen: https://it-a.eu/q1p16
[7] Zed Attack Proxy: https://it-a.eu/q1p17