Einheit 1.1: IONOS API, Authentifizierung und asynchrones Modell

Einführung

Sie werden TaskBoard erstellen, ein Task-Management-API mit einem Web-Frontend, und jedes Teil davon über Code auf IONOS Cloud bereitstellen. Kein Klicken im Data Center Designer. Bevor Sie einen einzelnen Server bereitstellen können, benötigen Sie drei Dinge, die korrekt konfiguriert sind: wie Sie authentifizieren, wie das API Ihnen mitteilt, dass eine Ressource tatsächlich bereit ist, und welchen Client (roher HTTP, SDK oder CLI) Sie in jeder Situation verwenden.

Diese Einheit ist der Vertrag, den Sie mit dem IONOS Cloud-API abschließen. Die wichtigste Tatsache, die Sie internalisieren sollten, ist, dass die Bereitstellung asynchron ist: ein POST gibt sofort eine Anforderungs-ID zurück, nicht eine fertige Ressource. Behandeln Sie die Antwort als "akzeptiert, arbeite daran" anstatt "fertig", und Sie vermeiden die häufigste Klasse von Automatisierungsfehlern auf dieser Plattform. Sie werden die Authentifizierung einrichten, den Polling-Loop erlernen, der jeden abhängigen Vorgang steuert, und einen Server über alle drei Schnittstellen bereitstellen, damit Sie sie direkt vergleichen können.

1. Der IONOS Cloud REST API

Jede TaskBoard-Ressource, die Sie erstellen, vom Rechenzentrum bis zum Server bis zur Load Balancer, geht durch den IONOS Cloud REST API. Der Cloud API ist versioniert und befindet sich unter einer einzigen Basis-URL. Alle Kern-Cloud-API-Aufrufe zielen auf https://api.ionos.com/cloudapi/v6 ab, und Anfragen und Antworten sind JSON (Content-Type: application/json).

Ressourcen werden hierarchisch adressiert. Ein Server beispielsweise befindet sich unter seinem Rechenzentrum: /datacenters/{datacenterId}/servers/{serverId}. Diese Verschachtelung ist wichtig, da Sie fast immer einen Elternteil vor einem Kind erstellen und der Elternteil zuerst vollständig bereitgestellt werden muss (siehe Abschnitt 3).

1.1 Basis-URL, Versionierung und Inhaltstypen

Die Cloud-API-Oberfläche ist an v6 im Pfad festgelegt. Binden Sie sie in Ihrem Code explizit an, anstatt auf einen unversionierten Alias zu vertrauen, damit ein Upstream-Versionssprung nie das Verhalten unter Ihrer Automatisierung stillschweigend ändert.

# Smoke-test connectivity and auth: list your datacenters
curl -s -X GET 'https://api.ionos.com/cloudapi/v6/datacenters?depth=1' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  -H 'Content-Type: application/json'

Der depth-Abfrageparameter steuert, wie viel des verschachtelten Ressourcenbaums zurückgegeben wird. depth=1 gibt die Sammlung mit den obersten Eigenschaften zurück; höhere Tiefen binden Kinder ein. Halten Sie depth bei Listenaufrufen niedrig, um die Payload-Größe zu reduzieren, und fordern Sie eine bestimmte Ressource nach ID an, wenn Sie vollständige Details benötigen.

1.2 Hinweis auf separate API-Hosts

Nicht jeder IONOS-Service befindet sich unter cloudapi/v6. Einige Dienste stellen ihre eigenen Hosts bereit (zum Beispiel verwendet IAM Federation https://iam.ionos.com, und der CDN verwendet einen regionalen Host). Wenn Sie diese Dienste in späteren Modulen integrieren, lesen Sie den Endpunkt aus der Dokumentation dieses Dienstes, anstatt anzunehmen, dass die Basis-Cloud-API gilt. Der Authentifizierungsheader bleibt jedoch über diese Hosts hinweg der gleiche Bearer-Token.

2. Authentifizierung

Die IONOS Cloud API akzeptiert zwei Authentifizierungsmethoden: ein Bearer-Token (die primäre, empfohlene Methode) und Basic-Authentifizierung mit Ihrem Kontonamen und Passwort.

Zwei operationale Fakten bestimmen die Wahl. Erstens müssen Konten mit aktiviertem oder erzwungenem 2FA die Bearer-Token-Authentifizierung verwenden. Zweitens ist die Basic-Authentifizierung als veraltet dokumentiert und sollte nur in Kombination mit 2FA verwendet werden. Die praktische Konsequenz für jede neue Automatisierung: Verwenden Sie Bearer-Tokens.

2.1 Bearer-Tokens über das Token Manager

Sie generieren Token über das API/SDK-Authentifizierungs-Token Manager (im DCD unter Menü > Verwaltung > Token Manager, über das API oder über die CLI). Ein Token ist eine Zeichenfolge, die Sie in der Authorization-Headerzeile auf jeder Anfrage platzieren.

# Bearer token on every CloudAPI request
curl -s -X GET 'https://api.ionos.com/cloudapi/v6/datacenters' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN"

Sie können ein Token programmgesteuert von der Token-Generierungs-Endpunkt anfordern und dann den Tokenwert für nachfolgende API- und SDK-Aufrufe wiederverwenden:

# Generate a token using Basic auth, then switch to the token for all later calls
TOKEN=$(curl -s -u "$IONOS_USERNAME:$IONOS_PASSWORD" \
  -X GET 'https://api.ionos.com/auth/v1/tokens/generate' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["token"])')

export IONOS_TOKEN="$TOKEN"

Beachten Sie, dass der Token-Generierungs-Host auth/v1 und nicht cloudapi/v6 ist. Das zurückgegebene Token wird dann gegen die Cloud-API verwendet.

2.2 Token-Lebenszyklus: Erstellung, Scoping und Rotation

Das Token Manager legt konkrete Grenzen fest, um die Sie herum planen müssen. Sie können bis zu 100 Authentifizierungstoken pro Benutzer generieren, und die Gültigkeitsdauer (TTL) jedes Tokens kann bei der Erstellung aus einer festen Menge von Optionen gewählt werden: 1 Stunde, 4 Stunden, 1 Tag, 7 Tage, 30 Tage, 60 Tage, 90 Tage, 180 Tage und 365 Tage.

Der Tokenwert wird genau einmal bei der Generierung angezeigt und kann danach nicht mehr abgerufen werden; Sie können ihn auch als Datei herunterladen, wenn er generiert wird. Fangen Sie ihn sofort in Ihrem Geheimnis-Speicher ein, da es später kein "erneutes Anzeigen" gibt.

Diese Grenzen prägen ein Muster mit minimalem Privileg und Rotation. Stellen Sie ein separates, kurzlebiges Token pro Dienst und pro Umgebung bereit (eines für die TaskBoard-CI-Pipeline, eines für den laufenden API-Dienst und so weiter), anstatt ein langlebiges Token überall zu teilen. Da Token aufgrund einer festen TTL ablaufen, ist die Rotation eine Routine, die Sie automatisieren, anstatt ein Feuerwehr-Manöver durchzuführen.

# Read the token from the environment, never hardcode it
import os

IONOS_TOKEN = os.environ["IONOS_TOKEN"]  # fails loudly if unset
# Hardcoding a 365-day token in source is the fastest way to leak credentials.

Die Obergrenze von 100 Token bedeutet, dass ein außer Kontrolle geratenes Skript, das pro Lauf ein frisches Token prägt, Ihr Kontingent erschöpfen wird. Prägen Sie einmal, speichern Sie, wiederverwenden Sie, bis zum Ablauf und dann rotieren Sie.

3. Das asynchrone Bereitstellungsmodell

Dies ist die Regel, die mehr IONOS-Automatisierung als jede andere bricht: Bereitstellungsoperationen sind asynchron. Ein POST oder PUT gibt keine fertige Ressource zurück. Es gibt 202 Accepted zurück, die neue Ressource tritt in einen BUSY-Zustand ein und ein Location-Header verweist auf eine Status-URL, die Sie abfragen, bis die Bereitstellung abgeschlossen ist.

Sie müssen auf den Abschluss warten, bevor Sie eine Operation ausführen, die von der neuen Ressource abhängt. Das Anfügen eines Volume an einen Server, der noch BUSY ist, oder das Erstellen einer NIC in einem halb bereitgestellten Rechenzentrum, schlägt fehl. Das asynchrone Modell ist nicht optional und es ist nichts, was Sie mit Wiederholungen des abhängigen Aufrufs allein umgehen können.

3.1 Die 202-Antwort und der Location-Header

Wenn Sie eine Ressource erstellen, ist der Antwortstatus 202 Accepted, der Textkörper enthält die neue Ressource id und der Antwortheader enthält eine Status-URL zum Abfragen.

# Create a datacenter; capture the request status URL from the Location header
curl -s -D - -o /tmp/dc.json \
  -X POST 'https://api.ionos.com/cloudapi/v6/datacenters' \
  -H 'Authorization: Bearer '"$IONOS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"properties":{"name":"taskboard-dc","location":"de/fra"}}' \
  | grep -i '^location:'

Der Location-Header enthält die Anfrage-Status-URL. Das Muster ist bei allen Ressourcentypen identisch: die Dokumentation für die Kern-Cloud-API-Endpunkte besagt, dass die Antwort einen Location-Header mit einer URL zur Abfrage des Anfragestatus enthält, und die Ressource hält einen BUSY-Status, bis die Bereitstellung abgeschlossen ist.

3.2 Abfrage bis DONE

Der Status-Endpunkt meldet den Zustand der Anfrage. Sie fragen ihn ab, bis der Zustand DONE ist (eine fehlgeschlagene Bereitstellung erscheint als FAILED). Erst dann gehen Sie zu den abhängigen Operationen über.

Die exakte Anfrage-Status-Payload-Form und die empfohlene Abfragehäufigkeit unten spiegeln die gängige IONOS-Automatisierungspraxis wider, anstatt einen wörtlichen Dokumentationsauszug wiederzugeben. Die Zustandswerte BUSY, DONE und FAILED sind dokumentationsbasiert, die Schleifenstruktur ist eine Standardimplementierung.

# Poll the status URL until the request reports DONE
STATUS_URL="https://api.ionos.com/cloudapi/v6/requests/<request-id>/status"

until [ "$(curl -s -H "Authorization: Bearer $IONOS_TOKEN" "$STATUS_URL" \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["metadata"]["status"])')" = "DONE" ]; do
  echo "still provisioning..."
  sleep 5
done
echo "resource ready"

Die SDKs übernehmen diese Schleife für Sie. Übergeben Sie die SDK-Option, die auf die Fertigstellung wartet und der Client intern abfragt, sodass Ihr Anwendungscode so liest, als ob der Aufruf synchron wäre, während er den asynchronen Modell darunter dennoch respektiert.

4. SDKs und die ionosctl-Kommandozeilenoberfläche

Sie werden keine rohe curl für die Anwendungslogik schreiben. IONOS veröffentlicht SDKs für Python (ionoscloud), Go (sdk-go), Java und JavaScript, sowie das ionosctl-Kommandozeilen-Tool. Alle authentifizieren sich mit dem gleichen Bearer-Token und alle müssen das asynchrone Modell berücksichtigen.

4.1 Das Python-SDK

Das Python-SDK verwendet ein Configuration-Objekt (das Ihren Token enthält), das in einem ApiClient eingeschlossen ist, das Sie dann an service-spezifische API-Klassen übergeben.

Die Klassen- und Methodennamen des SDK unten (Configuration, ApiClient, DataCentersApi, ServersApi und die datacenters_servers_post-Methode) spiegeln die veröffentlichte Schnittstelle des ionoscloud Python-SDK wider, die auf allgemeines Wissen basiert; überprüfen Sie die genauen Signaturen gegen die Version des SDK, die Sie festlegen.

import os
import ionoscloud
from ionoscloud.api import data_centers_api, servers_api
from ionoscloud.models import Server, ServerProperties

config = ionoscloud.Configuration(token=os.environ["IONOS_TOKEN"])

with ionoscloud.ApiClient(config) as api_client:
    servers = servers_api.ServersApi(api_client)
    server = Server(properties=ServerProperties(
        name="taskboard-api",
        cores=4,
        ram=8192,            # MB; 8 GB
        cpu_family="INTEL_SKYLAKE",
    ))
    # The SDK can wait for the async request to finish for you
    created = servers.datacenters_servers_post(
        datacenter_id=os.environ["TASKBOARD_DC_ID"],
        server=server,
    )
    print("server id:", created.id)

Das SDK liest Ihr Token aus dem Configuration-Objekt. Binden Sie die Lebensdauer dieses Objekts an die TTL des Tokens und aktualisieren Sie es, wenn Sie es rotieren.

4.2 Die ionosctl-Kommandozeilenoberfläche

ionosctl ist die schnellste Schnittstelle für Einmal-Aufgaben, Skripting und Inspektion. Authentifizieren Sie sich einmal, dann führen Sie Befehle aus.

Die Syntax des ionosctl-Befehls unten spiegelt die veröffentlichte Befehlsstruktur des Tools wider, die auf allgemeinem Wissen basiert. Bestätigen Sie die Flags gegen Ihre installierte CLI-Version mit ionosctl <command> --help.

# Authenticate the CLI with a token
ionosctl login --token "$IONOS_TOKEN"

# List datacenters
ionosctl datacenter list

# Create a server (ionosctl waits for the request by default)
ionosctl server create \
  --datacenter-id "$TASKBOARD_DC_ID" \
  --name taskboard-api --cores 4 --ram 8192

4.3 Auswahl einer Schnittstelle

Die folgende Tabelle vergleicht die vier Möglichkeiten, mit denen Sie mit dem IONOS Cloud API interagieren, damit Sie bewusst und nicht aus Gewohnheit wählen können.

Wie oben gezeigt, verwenden Sie das SDK für Anwendungslogik, ionosctl für schnelle Aufgaben und CI-Klebe, rohe HTTP, wenn Sie das Protokoll selbst debuggen, und Terraform (nächste Einheit) für alles, was als deklaratives Zustand existieren sollte.

5. Rate Limiting, Pagination und Fehlerbehandlung

Die Produktionsautomatisierung trifft auf drei Realitäten, die die happy-path-Beispiele auslassen: Der API limitiert Ihre Rate, Sammlungen sind paginiert und einige Fehlercodes bedeuten etwas anderes, als Sie erwarten.

5.1 Rate Limiting mit exponentiellem Backoff

Wenn Sie die AnfrageRate überschreiten, antwortet der API mit 429. Die richtige Antwort ist, sich exponentiell zurückzuziehen und zu wiederholen, anstatt den Endpunkt zu bombardieren.

Die Implementierung des exponentiellen Backoff unten ist ein Standardmuster für die clientseitige Wiederholung; die 429-Statussemantik ist dokumentationsbasiert, die spezifischen Verzögerungen und Jitter sind eine Implementierungsentscheidung.

import time, random, requests

def get_with_backoff(url, headers, max_retries=6):
    for attempt in range(max_retries):
        resp = requests.get(url, headers=headers)
        if resp.status_code != 429:
            resp.raise_for_status()
            return resp
        # Honor Retry-After if present, else exponential backoff with jitter
        wait = int(resp.headers.get("Retry-After", 2 ** attempt))
        time.sleep(wait + random.uniform(0, 1))
    raise RuntimeError("rate limit: retries exhausted")

5.2 Paginierung mit Offset und Limit

Listendpunkte geben paginierte Sammlungen zurück, die durch offset und limit gesteuert werden. Der limit-Parameter begrenzt die Anzahl der Elemente pro Seite, und offset legt den Startpunkt innerhalb der Sammlung fest. Bei Sammlungsendpunkten ist der Standard-limit 1000 und der Standard-offset ist 0.

# Iterate every page of a collection
def list_all(url, headers, page_size=1000):
    offset, items = 0, []
    while True:
        page = get_with_backoff(
            f"{url}?offset={offset}&limit={page_size}", headers
        ).json()
        batch = page.get("items", [])
        items.extend(batch)
        if len(batch) < page_size:
            break
        offset += page_size
    return items

Nehmen Sie nie an, dass ein einzelner Aufruf alles zurückgegeben hat. Wenn Sie genau limit Elemente zurückbekommen haben, gibt es fast sicherlich eine weitere Seite.

5.3 Fehlerbehandlung und die 404-Falle

Der Fehler, den Sie zuerst falsch interpretieren, ist 404 während der Bereitstellung. Ein 404 sofort nach der Erstellung einer Ressource bedeutet normalerweise, dass die Ressource noch nicht bereit ist, und nicht, dass sie fehlt. Dies ist das asynchrone Modell, das Sie beißt: Sie haben die Abfrage ausgelassen und eine untergeordnete Ressource abgefragt, bevor ihre übergeordnete Ressource den Zustand DONE erreicht hat.

# WRONG: create then immediately use -> intermittent 404
created = servers.datacenters_servers_post(datacenter_id=dc_id, server=server)
volumes.datacenters_volumes_post(datacenter_id=dc_id, volume=vol)  # may 404

# RIGHT: wait for DONE, then proceed (SDK wait option, or poll the status URL)

Lesen Sie Antworttexte bei Fehlern. IONOS-Fehlerantworten enthalten eine strukturierte Nutzlast mit dem HTTP-Code und einer menschenlesbaren Meldung. Protokollieren Sie diese, anstatt die Ausnahme zu verschlucken, sodass ein 429, ein fehlerhafter Textkörper (422) und ein Authentifizierungsfehler (401) in Ihrer Pipeline-Ausgabe sofort unterscheidbar sind.

API Referenz-Quick-Card

Wichtige API-Endpunkte für die Authentifizierung und das asynchrone Modell:

Basis-URL: https://api.ionos.com/cloudapi/v6 Token-Host: https://api.ionos.com/auth/v1 Authentifizierung: Authorization: Bearer <token>

Code-Lab

Ziel: Bereitstellung eines Servers auf drei Arten (curl, Python SDK, ionosctl) und Überprüfung der asynchronen Fertigstellung jedes Mal.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Zugriff
• curl, python3 und ionosctl lokal installiert
• Das ionoscloud Python SDK: pip install ionoscloud

Schritt 1: Generieren und Exportieren eines Tokens

export IONOS_TOKEN=$(curl -s -u "$IONOS_USERNAME:$IONOS_PASSWORD" \
  -X GET 'https://api.ionos.com/auth/v1/tokens/generate' \
  | python3 -c 'import sys,json; print(json.load(sys.stdin)["token"])')

Erwartete Ausgabe:

(no output; verify with: echo ${IONOS_TOKEN:0:8}...)

Schritt 2: Erstellen eines Rechenzentrums und Erfassen der Anfrage-Status-URL

curl -s -D /tmp/hdr -o /tmp/dc.json \
  -X POST 'https://api.ionos.com/cloudapi/v6/datacenters' \
  -H "Authorization: Bearer $IONOS_TOKEN" -H 'Content-Type: application/json' \
  -d '{"properties":{"name":"taskboard-dc","location":"de/fra"}}'
grep -i '^location:' /tmp/hdr
export DC_ID=$(python3 -c 'import json;print(json.load(open("/tmp/dc.json"))["id"])')

Erwartete Ausgabe:

location: https://api.ionos.com/cloudapi/v6/requests/<id>/status

Schritt 3: Abfragen, bis das Rechenzentrum FERTIG ist

STATUS=$(grep -i '^location:' /tmp/hdr | awk '{print $2}' | tr -d '\r')
until [ "$(curl -s -H "Authorization: Bearer $IONOS_TOKEN" "$STATUS" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["metadata"]["status"])')" = "DONE" ]; do sleep 5; done
echo done

Erwartete Ausgabe:

done

Schritt 4: Erstellen eines Servers über curl

curl -s -X POST "https://api.ionos.com/cloudapi/v6/datacenters/$DC_ID/servers" \
  -H "Authorization: Bearer $IONOS_TOKEN" -H 'Content-Type: application/json' \
  -d '{"properties":{"name":"srv-curl","cores":2,"ram":4096,"cpuFamily":"INTEL_SKYLAKE"}}'

Erwartete Ausgabe:

{"id":"<server-id>","type":"server", ... }

Schritt 5: Erstellen eines Servers über das Python SDK

import os, ionoscloud
from ionoscloud.api import servers_api
from ionoscloud.models import Server, ServerProperties
cfg = ionoscloud.Configuration(token=os.environ["IONOS_TOKEN"])
with ionoscloud.ApiClient(cfg) as c:
    s = servers_api.ServersApi(c).datacenters_servers_post(
        datacenter_id=os.environ["DC_ID"],
        server=Server(properties=ServerProperties(
            name="srv-sdk", cores=2, ram=4096, cpu_family="INTEL_SKYLAKE")))
    print("sdk server:", s.id)

Erwartete Ausgabe:

sdk server: <server-id>

Schritt 6: Erstellen eines Servers über ionosctl

ionosctl login --token "$IONOS_TOKEN"
ionosctl server create --datacenter-id "$DC_ID" --name srv-cli --cores 2 --ram 4096

Erwartete Ausgabe:

ServerId   Name      Cores   Ram     State
<id>       srv-cli   2       4096    BUSY -> AVAILABLE

Schritt 7: Auflisten aller Server und Bestätigen, dass drei existieren

ionosctl server list --datacenter-id "$DC_ID"

Erwartete Ausgabe:

srv-curl, srv-sdk, srv-cli all AVAILABLE

Validierungs-Checkliste:

• [ ] Token generiert und exportiert, nie hartcodiert
• [ ] Rechenzentrum erreichte den DONE-Status, bevor ein Server erstellt wurde
• [ ] Drei Server über drei verschiedene Schnittstellen erstellt
• [ ] Alle drei Server erreichten den AVAILABLE-Status

Aufräumen:

# Deleting the datacenter removes its child servers; avoids ongoing charges
ionosctl datacenter delete --datacenter-id "$DC_ID" --force

Häufige Fallstricke

1. Das Provisioning als synchron behandeln

   • Problem: Ihr Skript erstellt einen Server und bindet sofort ein Volume an, was zu einem intermittierenden 404 oder einem Konfliktfehler führt.
   • Warum es passiert: Der POST gibt den 202 Accepted mit der Ressource im BUSY-Zustand zurück; die Ressource ist noch nicht bereit.
   • Lösung: Pollen Sie die Status-URL aus dem Location-Header, bis DONE erreicht ist, oder verwenden Sie die Warte-auf-Fertigstellung-Option des SDK, bevor Sie einen abhängigen Aufruf tätigen.

2. Ein frischer Token für jeden Lauf erstellen

   • Problem: Ein geplanter Job hört nach einer Weile mit Authentifizierungsfehlern auf zu funktionieren, und Sie finden Dutzende von Token im Token Manager.
   • Warum es passiert: Jeder Benutzer ist auf 100 Token beschränkt; ein Skript, das pro Lauf ein Token generiert, erschöpft das Kontingent und verliert die Übersicht darüber, welches Token aktiv ist.
   • Lösung: Erstellen Sie ein Token pro Service/Umwelt, speichern Sie es in einem Geheimnis-Speicher, verwenden Sie es, bis sein TTL abläuft, und dann rotieren Sie es. Der Token-Wert wird nur einmal angezeigt, also erfassen Sie ihn bei der Erstellung.

3. Nur die erste Seite einer Sammlung lesen

   • Problem: Ein Listen-Vorgang verpasst Ressourcen jenseits der ersten 1000 Elemente stillschweigend.
   • Warum es passiert: Sammlungsendpunkte paginieren mit einem Standard-limit von 1000; Code, der offset/limit ignoriert, sieht eine Seite.
   • Lösung: Schleifen Sie mit zunehmendem offset, bis eine Seite weniger als limit Elemente zurückgibt (siehe Abschnitt 5.2).

Zusammenfassung

Sie besitzen nun den Vertrag, auf den sich alle späteren Einheiten stützen. Sie können sich mit einem Bearer-Token von der Token Manager authentifizieren, das asynchrone Bereitstellungsmodell respektieren, indem Sie requests/{id}/status bis DONE abfragen, und die gleiche Ressource über curl, die Python-SDK und ionosctl bereitstellen. Sie können auch die Automatisierung unter Last durch Rückgang auf 429 und Paginierung durch große Sammlungen aufrechterhalten. Mit dieser Grundlage wird die Infrastrukturarbeit von TaskBoard in Einheit 1.2 zu einer Frage der Ausdruck dieser Operationen in Terraform.

Wichtige Punkte:

• Die CloudAPI-Grund-URL ist https://api.ionos.com/cloudapi/v6; Token werden bei https://api.ionos.com/auth/v1/tokens/generate generiert.
• Die Bereitstellung ist asynchron: POST gibt 202 Accepted zurück, die Ressource wird BUSY, und Sie fragen die Location-Status-URL ab, bis DONE, bevor abhängige Operationen durchgeführt werden.
• Verwenden Sie Bearer-Token (Basic-Auth wird eingestellt und 2FA-Konten müssen Bearer verwenden); ein Benutzer kann bis zu 100 Token halten, jedes mit einer festen TTL von 1 Stunde bis 365 Tagen.
• Ein Tokenwert wird genau einmal angezeigt und ist nicht wiederherstellbar, daher sollten Sie ihn bei der Erstellung erfassen; Sie können ihn als Datei herunterladen, wenn er erstellt wird.
• Ein 404 direkt nach der Erstellung bedeutet normalerweise "noch nicht bereit", nicht "fehlend"; behandeln Sie 429 mit exponentiellem Rückgang und paginieren Sie Sammlungen mit offset/limit (Standardlimit 1000).

Wichtige Begriffe:

• Bearer-Token: Ein Zeichenkredit, der von der Token Manager ausgestellt wird, im Authorization: Bearer-Header gesendet wird und die primäre Authentifizierungsmethode für die IONOS Cloud-API ist.
• Asynchrones Bereitstellungsmodell: Das Plattformverhalten, bei dem Create-/Update-Aufrufe 202 und eine Location-Status-URL zurückgeben; die Ressource ist BUSY, bis die Bereitstellung DONE erreicht.
• Anfragestatus-Endpunkt: /cloudapi/v6/requests/{id}/status, der abgefragt wird, um zu erfahren, ob eine asynchrone Operation BUSY, DONE oder FAILED ist.
• Token-TTL: Die feste Lebensdauer, die bei der Token-Erstellung gewählt wird (1 Stunde bis 365 Tage), die Ihre Rotationsplanung bestimmt.
• Paginierung (Offset/Limit): Sammlungs-Endpunkt-Parameter, bei denen limit die Anzahl der Elemente pro Seite (Standard 1000) und offset den Startindex festlegt.

Nächste Schritte

Weiterlernen: Einheit 1.2: Terraform Provider und Core-Muster

Verwandte Themen:

• Einheit 1.2: Terraform Provider und Core-Muster
• Einheit 1.3: Wissensprüfung - Programmatische Grundlagen