Erstellen Sie Ihre eigene Steuerungsoberfläche

Der vorgeschlagene Version-eins-Vertrag trennt Katalogressourcen von Kontoresourcen. Standorte und Pläne unterstützen die Konfiguration. Dienste repräsentieren akzeptierte Konfigurationen und Erfüllungsstatus. Abrechnung enthält Rechnungen und Zahlungsstatus. Tickets unterstützen eine nachvollziehbare Support-Konversation. Die Website implementiert ihre eigenen Formulare und Arbeitsbereiche; die folgenden Beispiele sind ein Designvertrag, keine Routen zu einem öffentlichen API.

Das vorbereitete Authentifizierungsmodell verwendet ein Bearer-Token im Authorization-Header. Schreibgeschützte Katalog- oder Dienst-Scopes sollten keinen Dienst erstellen, neu aufbauen oder stornieren können. Schreib-Scopes benötigen eine eigene Entscheidung und einen Widerrufspfad. Bewahren Sie Anmeldeinformationen in einer privaten Serverumgebung auf und betten Sie niemals ein geheimes Token in eine Seite oder ein Browser-Bundle ein.

GET /v1/services
Authorization: Bearer <private-token>
Accept: application/json

# Proposed scope: services:read

Verwenden Sie eine stabile Kennung für jede Ressource und eine Anforderungs-ID für den Support. Mutierende Aufrufe sollten einen Idempotenzschlüssel annehmen, damit ein Wiederholungsversuch abgeglichen werden kann, anstatt eine weitere Bestellung zu erstellen.

POST /v1/services
Idempotency-Key: <one-key-per-request>

{
  "plan_id": "umbra-1",
  "location": "iceland",
  "billing_cycle": "monthly",
  "image": "Ubuntu"
}

Die vorgeschlagenen Ratenbegrenzungen auf Kontoebene betragen 60 Lesevorgänge pro Minute und 20 Schreibvorgänge pro Minute, mit einer Burst-Toleranz vom Doppelten dieser Werte. Eine abgelehnte Anfrage gibt HTTP 429 mit Retry-After zurück; Automatisierung sollte wie angewiesen warten und Backoff anwenden. Fehler sollten einen stabilen Code, eine für Menschen lesbare Nachricht und eine request_id enthalten, wobei sensible Details entfernt werden.

{
  "error": {
    "code": "unsupported_location",
    "message": "This plan is not listed in that region.",
    "request_id": "req_example"
  }
}

Das vorbereitete Webhook-Modell deckt Rechnungszahlung, Dienstbereitschaft, Sperrung und Ticket-Aktualisierungen ab. Die Zustellung sollte eine Ereignis-ID und einen Zeitstempel haben, mit einer HMAC-SHA256-Signatur, die über den ursprünglichen Anfragetext mit einem privaten Signaturschlüssel geprüft wird. Lehnen Sie veraltete oder ungültige Signaturen ab, deduplizieren Sie Ereignis-IDs und bestätigen Sie erst, nachdem das Ereignis dauerhaft akzeptiert wurde. Konsumenten müssen Zustellungen außerhalb der Reihenfolge und wiederholte Zustellungen tolerieren.

Der vorgeschlagene API-Pfad enthält seine Hauptversion. Additive Änderungen sollten bestehende Clients erhalten; inkompatible Änderungen benötigen eine neue Version und eine sechsmonatige Auslaufankündigung für die alte. Verfügbarkeit, SDKs und ein Produktions-API-Host dürfen erst nach Integration und Sicherheitsprüfung veröffentlicht werden.

Die Kontoanwendung hat Festadressen-Zahlungsanforderungen und ablaufende Server-USD-Angebote. Die Transaktionsbeobachtung ist eine vertrauensbasierte, nur serverseitige Integration; es gibt keinen öffentlichen Bestätigungsendpunkt, keinen verbundenen Blockchain-Monitor und keinen Bereitstellungs-Worker. Browser-Polling liest den bestehenden Zahlungsstatus des angemeldeten Kunden und kann keine Transaktion bestätigen. Der oben dargestellte illustrative öffentliche API- und Webhook-Vertrag bleibt zukünftige Designarbeit.

• Raten- und Beobachtungslogik auf dem Server schützen.
• Verknüpfen Sie wiederverwendete Empfangsziele mit einer verifizierten Transaktion und einer expliziten Bestellreferenz.
• Halten Sie Bezahltes und Bereitgestelltes getrennt; eine verifizierte Transaktion darf keine fiktive Hardware erzeugen.