Einheit 13 — CURL: Der direkte Weg
Was du nach dieser Einheit weißt: Du verstehst was CURL ist, kannst einen CURL-Befehl zerlegen und weißt wann und warum du CURL direkt auf dem Server ausführst statt in Postman zu testen.
Was ist CURL?
CURL (Client URL) ist ein Kommandozeilen-Werkzeug das HTTP-Anfragen schickt — ohne grafische Oberfläche, direkt im Terminal.
curl https://api.example.com/v1/customers/42 \
-H "Authorization: Bearer eyJhbGci..." \
-H "Accept: application/json"
Das macht dasselbe wie eine GET-Anfrage in Postman — aber als Text-Befehl im Terminal.
CURL-Befehl zerlegen
Ein typischer CURL-Befehl von einem API-Anbieter:
curl -X POST https://api.example.com/v1/orders \
-H "Content-Type: application/json" \
-H "Authorization: Bearer abc123token" \
-H "X-API-Version: 2" \
--data-raw '{
"customer_id": 42,
"product_id": 789,
"quantity": 3
}' \
--insecure
Jedes Element:
| Teil | Bedeutung |
|---|---|
-X POST | HTTP-Methode (GET ist Standard, muss bei anderen angegeben werden) |
https://... | Die URL |
-H "..." | Ein Header (wiederholbar für mehrere Header) |
--data-raw '...' | Request Body (aktiviert POST implizit) |
--insecure | SSL-Verifikation deaktivieren |
Weitere häufige Flags:
| Flag | Bedeutung |
|---|---|
-v | Verbose: zeigt den vollständigen Request und Response inkl. Header |
-o datei.json | Antwort in Datei speichern statt auf den Bildschirm |
-u user:pass | Basic Auth |
--data-urlencode | URL-Encoding für Formular-Daten |
-L | Umleitungen (301, 302) automatisch folgen |
--max-time 30 | Timeout in Sekunden |
Warum CURL auf dem Server ausführen?
Das ist der entscheidende Punkt deiner Frage:
Postman läuft auf deinem Laptop. Wenn du per VPN verbunden bist und Postman erfolgreich antwortet, hat dein Laptop die Verbindung aufgebaut — von deiner VPN-IP aus, mit deinen Laptop-Netzwerkeinstellungen.
42°OS läuft auf einem anderen Server mit einer anderen IP, in einem anderen Subnetz, mit anderen Firewall-Regeln.
Wenn du wissen willst ob 42°OS die API erreichen kann, musst du CURL auf dem Server ausführen auf dem 42°OS läuft — nicht auf deinem Laptop.
Per SSH auf den 42°OS-Server verbinden
SSH (Secure Shell) ist eine verschlüsselte Verbindung zum Terminal eines anderen Servers.
ssh deploy42@178.104.74.95
Nach dem Login bist du im Terminal des Servers. Jetzt kannst du CURL ausführen — und die Verbindung kommt von der Server-IP, nicht von deinem Laptop.
# Jetzt auf dem 42°OS-Server:
curl https://erp-api.kunde.intern/v1/customers/42 \
-H "Authorization: Bearer token123" \
-v
Wenn das klappt: die Verbindung von 42°OS zur API funktioniert. Der Fehler liegt woanders.
Wenn das nicht klappt: die Verbindung ist auf Netzwerkebene blockiert. Das Problem ist Infrastruktur, nicht Konfiguration.
CURL als Diagnose-Werkzeug
Bevor du Zeit damit verbringst den Post Agent zu konfigurieren, teste mit CURL ob die API überhaupt erreichbar ist:
# Schritt 1: Ist der Server erreichbar?
curl -v https://api.example.com/v1/health
# Schritt 2: Wird Authentifizierung akzeptiert?
curl -v https://api.example.com/v1/customers \
-H "Authorization: Bearer dein_token"
# Schritt 3: Klappt der echte Request?
curl -X POST https://api.example.com/v1/orders \
-H "Authorization: Bearer dein_token" \
-H "Content-Type: application/json" \
-d '{"customer_id": 1, "quantity": 1}' \
-v
Mit -v (verbose) siehst du:
* Trying 185.42.11.93:443...
* Connected to api.example.com (185.42.11.93) port 443
* SSL handshake complete
> POST /v1/orders HTTP/1.1
> Authorization: Bearer dein_token
> Content-Type: application/json
>
< HTTP/1.1 201 Created
< Content-Type: application/json
Jede Zeile erzählt dir etwas: DNS aufgelöst? TCP-Verbindung aufgebaut? SSL-Handshake erfolgreich? Request abgeschickt? Response erhalten?