Ihr Frontend-Team ist blockiert: Das Design steht, die Screens sind fast fertig, aber die API kommt erst im nächsten Sprint. Ein lokaler Mock hilft nur, solange Ihr Rechner läuft. Sobald Sie den Laptop schließen, ist der Endpunkt für QA, Kolleg:innen in anderen Zeitzonen oder Integrationspartner nicht mehr erreichbar.
Apidog noch heute ausprobieren
Apidog schließt diese Lücke mit Cloud Mock: Statt eines lokal laufenden Mocks erhalten Sie eine öffentlich erreichbare URL unter mock.apidog.com. Frontend, QA und Partner können damit realistische API-Antworten verwenden, bevor Backend-Code ausgeliefert wird. Eine Einführung liefert der Artikel über API-Mocks und ihre Einsatzbereiche. Für die Grundlagen öffentlicher Endpunkte ist auch die MDN-Referenz zum HTTP-Anfrage-/Antwortmodell hilfreich.
Was Cloud Mock ist – und wann lokale Mocks nicht reichen
Apidog generiert für jeden entworfenen Endpunkt einen Mock. Standardmäßig läuft dieser lokal über Ihre Apidog-Instanz. Das eignet sich für individuelles Debugging, ist aber keine belastbare Basis für Zusammenarbeit: Der Mock ist nur verfügbar, solange der Host-Rechner läuft.
Cloud Mock stellt denselben Mock als dauerhaft verfügbaren Endpunkt bereit. Die URL läuft unabhängig von Ihrem Rechner auf dem gehosteten Dienst von Apidog.
Damit entsteht ein klarer Workflow:
- API-Vertrag definieren.
- Cloud Mock aktivieren.
- Öffentliche URL teilen.
- Frontend entwickelt gegen realistische Antworten.
- QA erstellt Tests gegen dieselbe Antwortstruktur.
- Partner integrieren frühzeitig gegen den Vertrag.
Für verteilte Teams behandelt der Artikel Mock-Server und Umgebungen für globale Teams den Workflow ausführlicher.
Cloud Mock aktivieren und öffentliche URL teilen
Nehmen wir einen users-Service mit einem Endpunkt GET /users, der Kundendatensätze zurückgibt.
Schritt 1: Cloud Mock im Projekt aktivieren
Öffnen Sie in Apidog:
Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen
Aktivieren Sie Cloud Mock.
Diese Einstellung gilt projektweit. Danach verfügt jeder Endpunkt zusätzlich zur lokalen Mock-URL über eine Cloud-Mock-URL.
Schritt 2: Cloud-Mock-URL kopieren
Öffnen Sie GET /users, wechseln Sie zum Tab Mock und kopieren Sie die Cloud-Mock-URL. Sie sieht beispielsweise so aus:
https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
Die URL folgt einem Muster wie diesem:
mock.apidog.com/m1/<projectId>-<num>-<env>/<path>
Erstellen Sie diese URL nicht manuell. Verwenden Sie immer die von Apidog kopierte URL als Quelle der Wahrheit.
Schritt 3: Mock-Antwort in Apidog prüfen
Senden Sie im Tab Mock eine Anfrage an die generierte URL. Prüfen Sie vor dem Teilen insbesondere:
- HTTP-Status
- Antwortstruktur
- Datentypen
- Beispielwerte
- erwartete Header
Ein Mock für GET /users könnte etwa diese Antwort liefern:
[
{
"id": 1,
"name": "Amelia Turner",
"email": "amelia.turner@example.com",
"city": "Portland"
},
{
"id": 2,
"name": "Marcus Bell",
"email": "marcus.bell@example.com",
"city": "Austin"
}
]
Apidog generiert diese Werte auf Basis der Feldnamen und Typen Ihres Schemas. Dadurch kann das Frontend Tabellen, Listen und Detailansichten mit plausiblen Daten entwickeln.
Schritt 4: Den Endpunkt im Browser und per curl testen
Für GET-Anfragen können Sie die vollständige Cloud-Mock-URL direkt im Browser öffnen. Das ist praktisch für einen schnellen Smoke-Test oder für Stakeholder, die nur die JSON-Antwort prüfen müssen.
Für die Entwicklung rufen Sie den Endpunkt wie jede andere API auf:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Damit ist der Ablauf abgeschlossen: Vertrag entwerfen, Cloud Mock aktivieren, URL kopieren und teilen.
Cloud Mock mit Token-Authentifizierung schützen
Eine öffentliche URL ist praktisch, aber nicht immer erwünscht. Wenn Ihr Mock unveröffentlichte Features oder Partnerintegrationen abbildet, aktivieren Sie den Zugriffsschutz.
Navigieren Sie zu:
Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen
Setzen Sie die Zugriffsberechtigung auf Token-Authentifizierung.
Danach muss jede Anfrage einen gültigen apidogToken enthalten. Sie können den Token auf drei Arten senden.
Token als Query-Parameter
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Token als Request-Header
Der Header-Ansatz vermeidet, dass der Token in vollständigen URLs oder Serverprotokollen erscheint.
curl "https://mock.apidog.com/m1/2689726-0-default/users" \
-H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Token als Body-Parameter
Sie können apidogToken auch als Body-Parameter in form-data- oder x-www-form-urlencoded-Anfragen senden. Das ist für Clients relevant, die Formularinhalte übermitteln.
Für Frontend-Code ist ein Header meist die sauberste Option:
const res = await fetch(
"https://mock.apidog.com/m1/2689726-0-default/users",
{
headers: {
apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
}
}
);
const users = await res.json();
Wenn Sie Token-Authentifizierung nachträglich aktivieren, müssen alle Consumer ihre Requests anpassen. Stimmen Sie die Umstellung mit QA, Frontend und Partnern ab, bevor bestehende Aufrufe fehlschlagen.
Regionsspezifische Mock-Daten mit Locales generieren
Mocks mit Werten wie "name": "string" prüfen nur die Datenform. Realistische Namen, Adressen und Telefonnummern helfen dagegen, UI-Probleme früh zu finden:
- abgeschnittene Texte
- fehlerhafte Adressformate
- Probleme mit nicht-lateinischen Zeichen
- Layoutfehler bei längeren Namen
- inkorrekte Datums- und Zeitdarstellung
Apidog verwendet dafür Faker.js.
Standard-Locale über die Projektsprache festlegen
Standardmäßig orientiert sich Faker an der Spracheinstellung Ihres Projekts. Konfigurieren Sie diese unter:
Projekt-Einstellungen > Allgemeine Einstellungen
Die ausgewählte Sprache wird zur Standard-Locale für generierte Mock-Werte. Wenn das Projekt auf Französisch eingestellt ist, erzeugt der Mock beispielsweise französisch wirkende Namen und Adressen.
Locale für das gesamte Projekt überschreiben
Sie können die Mock-Locale unabhängig von der Projektsprache festlegen:
Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen
Wählen Sie dort eine Faker-Locale aus. Diese Einstellung überschreibt die Sprache aus den allgemeinen Projekteinstellungen für alle Felder im Projekt.
Das ist besonders nützlich für Internationalisierungstests. Wenn Sie beispielsweise eine japanische Nutzerbasis simulieren, sehen Sie frühzeitig, wie Ihre Oberfläche mit anderen Zeichensätzen und Adressformaten umgeht.
Die schema-basierte Datengenerierung beschreibt der Artikel über Apidogs Smart Mock detaillierter.
Locale pro Feld überschreiben
Für gemischte Datensätze können Sie die Locale direkt im Mock-Ausdruck setzen:
{{$person.fullName(locale='ja')}}
Damit wird nur dieses Feld mit japanischen Namen generiert, zum Beispiel:
田中 太郎
Die Priorität ist:
- Feldbezogene Locale
- Projektbezogene Locale
- Standard aus den allgemeinen Projekteinstellungen
Verwenden Sie feldbezogene Overrides nur für echte Ausnahmen, etwa bei internationalen Kundenlisten.
Die Dokumentation zeigt ja als Beispiel, veröffentlicht aber keine vollständige Liste unterstützter Locales. Prüfen Sie deshalb den passenden Code in der Apidog-Mock-Dokumentation. Die verfügbaren Faker-Konventionen finden Sie in der Faker.js-Locale-Referenz.
Zeitzone ebenfalls konfigurieren
Neben der Locale lässt sich auch eine Zeitzone konfigurieren:
- projektweiter Standard unter Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen
- feldbezogen über den Parameter
timeZoneim Mock-Ausdruck
Das ist relevant, wenn Ihr Frontend Zeitstempel wie createdAt rendert. So bleiben die generierten Werte konsistent mit der simulierten Region.
Eine Übersicht weiterer Szenarien bietet der Artikel zu praktischen API-Mocking-Anwendungsfällen.
Cloud Mock oder selbst gehosteter Mock?
Cloud Mock ist die gehostete Option von Apidog. Sie eignet sich, wenn Ihr Team einen wartungsfreien, dauerhaft erreichbaren Endpunkt benötigt.
Selbsthosting ist sinnvoll, wenn Vorgaben wie diese gelten:
- Datenresidenz
- interne Infrastrukturvorgaben
- kein Testverkehr über die Cloud eines Anbieters
- vollständige Betriebskontrolle
Der Trade-off ist klar:
| Option | Vorteil | Aufwand |
|---|---|---|
| Cloud Mock | Keine Einrichtung, dauerhaft verfügbar | Gehosteter Dienst |
| Selbsthosting | Volle Kontrolle über Infrastruktur | Betrieb und Wartung liegen beim Team |
Der Leitfaden zum Self-Hosting des Apidog Mock-Servers beschreibt den Ablauf. Für einen Marktvergleich siehe den Vergleich von Online-API-Mocking-Tools.
Für Cloud Mock und Locale-Funktionen nennt die hier beschriebene Dokumentation keine konkrete Plananforderung. Prüfen Sie daher die Verfügbarkeit direkt in Ihrem Workspace. Sie können Apidog herunterladen und den Workflow in Ihrem Konto testen.
Den Workflow mit der Apidog CLI automatisieren
Cloud Mock wird nicht über ein Terminal gestartet oder betrieben. Die Apidog CLI startet keinen Mock-Server.
Sie hilft aber dabei, die Grundlage des Mocks aktuell zu halten: Endpunkte und Schemas. Wenn Sie API-Spezifikationen mit der CLI oder KI-Coding-Agenten wie Cursor oder Claude Code aktualisieren, liest Cloud Mock die aktualisierten Schemas für die Datengenerierung.
Sobald das Backend implementiert ist, können Sie gespeicherte Testszenarien headless gegen die Zielumgebung ausführen:
apidog run -t <scenario_id> -e <env_id> -r cli
Der Befehl führt ein Testszenario gegen eine Umgebung aus und meldet die Ergebnisse. So verwenden Mock und Backend-Tests dieselbe API-Spezifikation als gemeinsame Quelle der Wahrheit.
Kopieren Sie den von Apidog generierten Befehl direkt aus dem Szenario. Dann sind -t für die Szenario-ID und -e für die Umgebungs-ID bereits korrekt ausgefüllt. Für die Einbindung in CI/CD lesen Sie den Leitfaden zum Ausführen von Apidog in einer CI/CD-Pipeline.
FAQ
Funktioniert die Cloud-Mock-URL, wenn ich Apidog schließe?
Ja. Das ist der Zweck von Cloud Mock. Anders als ein lokaler Mock bleibt ein Cloud Mock über Apidogs Infrastruktur erreichbar, unabhängig davon, ob Ihr Rechner eingeschaltet ist.
Kann ich die Cloud-Mock-URL direkt im Browser verwenden?
Für GET-Anfragen ja. Öffnen Sie die vollständige URL einschließlich apidogToken, um die JSON-Antwort zu sehen.
Für andere HTTP-Methoden oder wenn der Token nicht in der Browser-Historie erscheinen soll, verwenden Sie curl, einen API-Client oder Ihren Frontend-Client und senden den Token als Header.
Was passiert ohne Token?
Wenn Token-Authentifizierung aktiviert ist, werden Requests ohne gültigen apidogToken abgelehnt. Senden Sie den Token als Query-Parameter, Header oder Body-Parameter in einer Formularanfrage.
Wie erzeuge ich Mock-Daten für ein bestimmtes Land?
Sie haben drei Ebenen:
- Projekt-Locale unter Allgemeine Einstellungen
- Projektweite Mock-Locale unter Funktions-Einstellungen > Mock-Einstellungen
- Feldbezogene Locale im Mock-Ausdruck, zum Beispiel:
{{$person.fullName(locale='ja')}}
Die Feldebene überschreibt die Projektebene, die wiederum die allgemeine Projekteinstellung überschreibt. Weitere Details enthält die Smart-Mock-Anleitung.
Sollte ich Cloud Mock oder ein Headless-Mock-Tool verwenden?
Cloud Mock eignet sich für Teams, die einen gehosteten Endpunkt ohne Betriebsaufwand benötigen und dessen Antworten an ihr API-Design binden wollen.
Wenn Mocks direkt in automatisierte Builds eingebettet werden sollen, vergleichen Sie die Optionen im Überblick zu Headless-Mock-Tools. Eine saubere API-Spezifikation bleibt in beiden Fällen entscheidend; für viele Tools bildet die OpenAPI-Initiative die Grundlage.
Zusammenfassung
Ein lokaler Mock entblockiert nur die Person, auf deren Rechner er läuft. Cloud Mock macht daraus eine teilbare mock.apidog.com-URL, die Frontend, QA und Partner verwenden können.
Der praktische Ablauf:
- Endpunkt und Schema definieren.
- Cloud Mock aktivieren.
- Antwort prüfen.
- Öffentliche URL teilen.
- Bei Bedarf Token-Authentifizierung aktivieren.
- Locale und Zeitzone für realistische Testdaten konfigurieren.
- Nach Backend-Implementierung dieselbe Spezifikation für CLI-Tests verwenden.
Laden Sie Apidog herunter, um Ihren ersten teilbaren Cloud Mock einzurichten.
Top comments (0)