Ihr Frontend-Team ist blockiert. Das Design ist freigegeben, die Bildschirme sind halb fertig, und das Einzige, was im Weg steht, ist eine API, die noch nicht existiert. Das Backend ist noch einen Sprint entfernt, sodass die Benutzeroberfläche nichts Reales aufrufen kann. Die übliche Übergangslösung ist ein lokaler Mock, und dieser funktioniert genau bis zu dem Moment, in dem Sie Ihren Laptop schließen. Dann ist der Endpunkt, den Ihr Teamkollege in einer anderen Zeitzone aufgerufen hat, nicht mehr erreichbar.
Das ist die Lücke, die Apidog mit Cloud Mock schließt. Anstatt eines Mocks, der auf einem einzigen Rechner lebt und stirbt, erhalten Sie eine öffentliche URL, die unter mock.apidog.com gehostet wird und rund um die Uhr verfügbar ist. Frontend-, QA- und Partnerentwickler können alle realistische Endpunkte aufrufen, bevor eine einzige Zeile Backend-Code ausgeliefert wird. Wenn Sie sich zuerst einen umfassenderen Überblick darüber verschaffen möchten, welche Vorteile Mocking einem Team bietet, bildet unser Einführungstext über was ein API-Mock ist und wann man ihn verwendet die Grundlage. Für die Funktionsweise, wie eine öffentliche Mock-URL in die Anforderungsverarbeitung passt, ist die MDN-Referenz zum HTTP-Anfrage-/Antwortmodell eine gute Auffrischung.
Was Cloud Mock ist und warum lokale Mocks nicht ausreichen
Apidog generiert einen Mock-Endpunkt für jede von Ihnen entworfene API. Standardmäßig ist dieser Mock ein lokaler Mock: Er läuft über Ihre Apidog-Instanz und antwortet, solange Ihr Rechner eingeschaltet ist. In dem Moment, in dem Sie herunterfahren, reagiert der Endpunkt nicht mehr. Das ist für das individuelle Debugging in Ordnung. Es funktioniert nicht mehr, sobald jemand anderes von der URL abhängig ist.
Cloud Mock ist die Lösung. Es ist ein ständig verfügbarer Mock-Endpunkt, der unabhängig von jedem einzelnen Rechner besteht. Die Computer Ihrer Teamkollegen können ausgeschaltet sein, Ihr Laptop kann in einer Tasche sein, und der Cloud Mock beantwortet weiterhin rund um die Uhr Anfragen. Der Endpunkt befindet sich auf dem gehosteten Dienst von Apidog, sodass die Verfügbarkeit nicht davon abhängt, wer online ist.
Der praktische Nutzen ist eine reibungslose Übergabe. Sie entwerfen den Vertrag, aktivieren Cloud Mock und teilen eine URL. Das Frontend entwickelt mit realistischen Daten, die QA schreibt Testfälle gegen echte Antwortstrukturen, und ein Partner, der sich mit Ihnen integriert, kann seinen Client sofort anbinden. Niemand wartet auf das Backend, und niemand wartet darauf, dass Sie einen Prozess am Laufen halten. Wenn Sie dies über Regionen hinweg koordinieren, gehen die Muster in Mock-Servern und Umgebungen mit globalen Teams teilen tiefer auf den Workflow ein.
Cloud Mock aktivieren und Ihre öffentliche URL erhalten
Gehen wir es anhand einer realistischen API durch. Angenommen, Sie erstellen einen users-Dienst mit einem GET /users-Endpunkt, der eine Liste von Kundendatensätzen zurückgibt. So verwandeln Sie das in einen teilbaren Cloud-Endpunkt.
Schritt 1: Cloud Mock aktivieren
Öffnen Sie Ihr Projekt und gehen Sie zu Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen. Aktivieren Sie Cloud Mock. Das ist der Schalter, der Apidog anweist, Ihre Mocks auf seinem ständig verfügbaren Dienst zu hosten, anstatt sie nur lokal bereitzustellen.
Sie tun dies nur einmal pro Projekt. Nach der Aktivierung erhält jeder Endpunkt im Projekt eine Cloud-Mock-URL zusätzlich zu seiner lokalen URL.
Schritt 2: Die Cloud-Mock-URL kopieren
Öffnen Sie den Endpunkt, den Sie teilen möchten, in diesem Fall GET /users. Gehen Sie zum Tab Mock und kopieren Sie die Cloud-Mock-URL. Sie erhalten etwas in dieser Form:
https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
Die Pfadstruktur folgt einem Muster: mock.apidog.com/m1/<projectId>-<num>-<env>/<path>. Apidog erstellt diese für Sie, sodass Sie sie nicht manuell zusammenbauen müssen. Beachten Sie, dass die Dokumentation dies anhand eines Beispiels zeigt, anstatt eine feste Vorlage zu veröffentlichen. Behandeln Sie daher die kopierte URL als Quelle der Wahrheit, anstatt zu versuchen, selbst eine zu erstellen.
Schritt 3: Den Mock sofort in Apidog testen
Bevor Sie die URL weitergeben, vergewissern Sie sich, dass sie das zurückgibt, was Sie erwarten. Senden Sie auf demselben Tab Mock eine Testanfrage an die Mock-URL. Apidog sendet die Anfrage und zeigt Ihnen die Antwort direkt an. Sie sehen sofort, ob die generierten Daten korrekt aussehen.
Ein GET /users-Mock könnte so zurückkommen:
[
{
"id": 1,
"name": "Amelia Turner",
"email": "amelia.turner@example.com",
"city": "Portland"
},
{
"id": 2,
"name": "Marcus Bell",
"email": "marcus.bell@example.com",
"city": "Austin"
}
]
Diese Werte sind nicht fest kodiert. Apidog liest die Feldnamen und Typen Ihres Schemas und generiert plausible Daten dazu, was den Mock für ein Frontend nützlich macht, das eine realistisch aussehende Tabelle rendert.
Schritt 4: Die URL in einem Browser öffnen
Für eine GET-Anfrage funktioniert die Cloud-Mock-URL direkt in einem Webbrowser. Fügen Sie sie in die Adressleiste ein und Sie sehen die JSON-Antwort. Dies ist der schnellste Schnelltest, den Sie einem nicht-technischen Stakeholder geben können: kein Client, kein Curl, nur ein Link, der Daten zurückgibt.
Für alles, was über einen kurzen Blick hinausgeht, ruft Ihr Frontend ihn wie jeden anderen Endpunkt auf:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Das ist der gesamte Kreislauf. Entwerfen Sie den Endpunkt, aktivieren Sie Cloud Mock, kopieren Sie die URL, und Ihr Team ist nicht mehr blockiert.
Den Mock mit Token-Authentifizierung absichern
Eine öffentliche URL ist praktisch, und manchmal zu praktisch. Wenn Ihr Mock eine unveröffentlichte Funktion oder eine Partnerintegration widerspiegelt, die Sie lieber nicht freigeben möchten, können Sie ihn schützen.
Gehen Sie zu Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen und setzen Sie die Zugriffsberechtigung auf Token-Authentifizierung. Sobald dies aktiviert ist, muss jede Anfrage ein gültiges apidogToken enthalten, und Anfragen ohne dieses werden abgelehnt. Sie können den Token auf drei Arten bereitstellen:
Als URL-Abfrageparameter, den die kopierte URL bereits verwendet:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Als Anfrage-Header, der den Token aus der URL und aus den Serverprotokollen heraushält:
curl "https://mock.apidog.com/m1/2689726-0-default/users" \
-H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Oder als Body-Parameter namens apidogToken in einer form-data- oder x-www-form-urlencoded-Anfrage, was für Clients geeignet ist, die Formularinhalte senden.
Für Frontend-Code ist der Header-Ansatz in der Regel am saubersten. Er hält den Token aus allem fern, was vollständige URLs protokolliert, und trennt die Anmeldeinformationen vom Ressourcenpfad:
const res = await fetch(
"https://mock.apidog.com/m1/2689726-0-default/users",
{ headers: { apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi" } }
);
const users = await res.json();
Eine Sache, die Sie beachten sollten: Wenn Sie die Token-Authentifizierung aktivieren, nachdem Sie bereits eine einfache URL geteilt haben, muss jeder Consumer den Token hinzufügen, sonst beginnen seine Aufrufe fehlzuschlagen. Koordinieren Sie die Umstellung, damit QA und Partner nicht vor abgelehnten Anfragen sitzen.
Realistische, regionsspezifische Daten mit Locales generieren
Ein Mock, der "name": "string" für jeden Datensatz zurückgibt, lehrt Ihre Benutzeroberfläche nichts. Ein Mock, der realistisch aussehende Namen, Adressen und Telefonnummern zurückgibt, ermöglicht es dem Frontend, Layoutfehler, Textüberläufe und Formatierungsprobleme zu erkennen, bevor echte Daten eintreffen. Apidog erledigt dies im Hintergrund mit Faker.js, und die Locale-Steuerung ist der Punkt, an dem es für internationale Produkte wirklich nützlich wird.
So funktioniert die Standard-Locale
Standardmäßig folgt Faker der Spracheinstellung Ihres Projekts. Diese wird unter Projekt-Einstellungen > Allgemeine Einstellungen konfiguriert, und die dort ausgewählte Sprache wird zur Standard-Locale für alle generierten Mock-Werte. Stellen Sie das Projekt auf Französisch ein, und Ihre Mock-Namen und -Adressen werden französisch geprägt zurückgegeben, ohne dass Sie feldspezifische Anpassungen vornehmen müssen.
Die Locale für das gesamte Projekt überschreiben
Wenn Sie Mock-Daten in einer bestimmten Locale wünschen, die von der Projektsprache abweicht, können Sie diese überschreiben. Gehen Sie zu Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen und wählen Sie eine Faker-Locale aus dem Dropdown-Menü. Diese Überschreibung hat Vorrang vor der Standardsprache der Allgemeinen Einstellungen für jedes Feld im Projekt.
Dies ist praktisch, wenn Sie die Internationalisierung testen. Stellen Sie die Projekt-Locale auf Japan ein, und jede generierte Adresse, jeder Name und jede Telefonnummer spiegeln diese Region wider, sodass Sie sehen können, wie sich Ihre Benutzeroberfläche gegenüber nicht-lateinischen Schriftzeichen und verschiedenen Adressformaten verhält. Das automatische Generieren solcher schema-bewussten Daten ist ein eigenständiges Thema, und die Anleitung zu Apidogs Smart Mock und wie er Ihr Schema liest behandelt die Generierungsseite ausführlich.
Die Locale Feld für Feld überschreiben
Manchmal benötigen Sie ein Feld in einer anderen Locale als den Rest, beispielsweise eine Kundenliste, die Regionen mischt. Sie können die Locale direkt im Mock-Ausdruck mit dem locale parameter festlegen:
{{$person.fullName(locale='ja')}}
Das gibt japanische Namen wie 田中 太郎 nur für dieses Feld aus, während der Rest der Antwort der Projekt-Locale folgt. Die Reihenfolge der Prioritäten verläuft in drei Ebenen: eine feldbezogene Locale überschreibt die projektbezogene Locale, die wiederum den Standard der Allgemeinen Einstellungen überschreibt. Sie legen also einen sinnvollen Projektstandard fest und greifen nur dort auf feldbezogene Überschreibungen zurück, wo Sie tatsächlich eine Ausnahme benötigen.
Ein kurzer ehrlicher Hinweis zum Umfang: Die Dokumentation zeigt ja als Beispiel und veröffentlicht keine vollständige Liste der unterstützten Locales. Bestätigen Sie daher den genauen Code für Ihre Zielregion in der Apidog Mock-Dokumentation, bevor Sie sich darauf verlassen. Fakers eigene Konventionen sind in der Faker.js Locale-Referenz dokumentiert.
Auch die Zeitzone anpassen
Es gibt eine parallele Steuerung für die Zeit. Ein projektweiter Standard befindet sich unter Projekt-Einstellungen > Funktions-Einstellungen > Mock-Einstellungen, und Sie können ihn pro Feld mit dem timeZone parameter innerhalb eines Mock-Ausdrucks überschreiben. Wenn Ihre Benutzeroberfläche Zeitstempel rendert, bleiben die generierten createdAt-Werte konsistent mit der von Ihnen simulierten Region, anstatt standardmäßig den Standort Ihres Servers zu verwenden.
Zwischen Locale- und Zeitzonen-Steuerungen können Sie einen Mock aufsetzen, der überzeugend eine japanische Nutzerbasis, eine deutsche oder eine gemischte internationale Kohorte imitiert, alles aus demselben Endpunktschema. Für die breitere Palette von Szenarien, die dies ermöglicht, ist die Zusammenfassung der praktischen Anwendungsfälle für API-Mocking einen Blick wert.
Cloud Mock versus selbst gehosteter Mock
Cloud Mock ist Apidogs gehostete Option und deckt die meisten Teams ab. Wenn Ihr Unternehmen Datenresidenzregeln oder eine Richtlinie gegen das Routing von Testverkehr über die Cloud eines Anbieters hat, unterstützt Apidog auch den Betrieb des Mock-Dienstes auf Ihrer eigenen Infrastruktur. Der Kompromiss ist einfach: Die Cloud-Option erfordert keine Einrichtung und ist immer online, während das Selbsthosting Ihnen die Kontrolle auf Kosten des eigenen Betriebs des Dienstes gibt. Wenn dies Ihre Situation ist, führt Sie der Leitfaden zum Self-Hosting des Apidog Mock-Servers durch die Schritte. Für Teams, die gehostete Optionen vergleichen, stellt der Vergleich von Online-API-Mocking-Tools die Landschaft dar.
Zur Planbegrenzung eine direkte Antwort: Die hier dokumentierten Cloud Mock- und Locale-Funktionen geben keine spezifische Plananforderung an. Es ist daher am ehrlichsten, die aktuelle Verfügbarkeit in Ihrem eigenen Konto zu überprüfen, anstatt sich auf eine Angabe aus einem Blogbeitrag zu verlassen. Sie können Apidog herunterladen und den gesamten Ablauf testen, um genau zu sehen, was Ihr Arbeitsbereich umfasst.
Den Workflow mit der Apidog CLI automatisieren
Mocking in Apidog ist eine GUI- und Cloud-Funktionalität. Die Mock-Antworten werden automatisch aus Ihrem Endpunktschema generiert und von Apidogs gehosteter Engine bereitgestellt, nicht von etwas, das Sie in einem Terminal ausführen. Die ehrliche Formulierung ist also diese: Die Apidog CLI startet oder betreibt keinen Mock-Server. Was sie tut, ist, die Eingaben für Ihren Mock präzise zu halten.
Die CLI und KI-Coding-Agenten wie Cursor oder Claude Code können die Endpunkte und Schemas in Ihrem Projekt erstellen und aktualisieren. Da der Cloud Mock diese Schemas liest, um Daten zu generieren, sorgt die Aktualität der Spezifikation dafür, dass die Mock-Ausgabe während der Entwicklung der API korrekt bleibt. Wenn Sie ein agentenbasiertes Tool verwenden, um ein Feld hinzuzufügen, spiegelt der Mock dies ohne manuelle Bearbeitung wider.
Sobald der Mock die Frontend-Arbeit freigegeben hat und das echte Backend implementiert ist, werden die Testszenarien desselben Projekts Headless dagegen ausgeführt. Der Ausführungsbefehl der CLI validiert das Live-Backend gegen denselben Vertrag, den der Mock beschrieben hat:
apidog run -t <scenario_id> -e <env_id> -r cli
Dieser einzelne Befehl führt ein gespeichertes Testszenario gegen eine Umgebung aus und meldet die Ergebnisse, sodass der Mock, der die Benutzeroberfläche freigegeben hat, und die Tests, die das Backend verifizieren, beide auf eine einzige Quelle der Wahrheit zurückgeführt werden. Öffnen Sie Ihr Szenario in Apidog und kopieren Sie den generierten Befehl mit der bereits ausgefüllten -t Szenario-ID und -e Umgebungs-ID, anstatt die Flags manuell zusammenzustellen. Das Einbinden in eine Pipeline wird im Leitfaden zum Ausführen von Apidog in einer CI/CD-Pipeline behandelt.
FAQ
Funktioniert die Cloud-Mock-URL weiterhin, wenn ich Apidog schließe?
Ja, das ist der gesamte Sinn von Cloud Mock. Im Gegensatz zu einem lokalen Mock, der aufhört zu reagieren, wenn der Host-Rechner heruntergefahren wird, wird der Cloud Mock von Apidogs Infrastruktur bereitgestellt und bleibt 24/7 verfügbar. Ihre Teamkollegen können darauf zugreifen, unabhängig davon, ob Ihr Computer eingeschaltet ist.
Kann ich die Cloud-Mock-URL direkt im Browser verwenden?
Für GET-Anfragen, ja. Fügen Sie die vollständige URL, einschließlich des apidogToken Abfrageparameters, in Ihre Adressleiste ein, und Sie sehen die JSON-Antwort. Für andere Methoden oder um den Token aus Ihrer URL-Historie herauszuhalten, rufen Sie ihn mit einem Tool wie curl oder Ihrem Frontend-Client auf und übergeben Sie den Token stattdessen als Header.
Was passiert mit Anfragen, die den Token nicht enthalten?
Wenn Sie die Zugriffsberechtigung auf Token-Authentifizierung gesetzt haben, wird jede Anfrage ohne einen gültigen apidogToken abgelehnt. Übergeben Sie ihn als Abfrageparameter, als Request-Header oder als Body-Parameter in einer Formularanfrage. Wenn Sie die Token-Authentifizierung aktivieren, nachdem Sie eine einfache URL geteilt haben, informieren Sie Ihre Consumer, damit sie den Token hinzufügen können, bevor ihre Aufrufe fehlschlagen.
Wie erhalte ich Mock-Daten, die zu einem bestimmten Land passen?
Legen Sie Ihre Projekt-Locale in den Allgemeinen Einstellungen fest, oder überschreiben Sie diese für das gesamte Projekt unter Funktions-Einstellungen > Mock-Einstellungen, oder überschreiben Sie ein einzelnes Feld mit dem locale-Parameter im Mock-Ausdruck, z. B. {{$person.fullName(locale='ja')}}. Feldebene schlägt Projektebene, welche den Standard der Allgemeinen Einstellungen schlägt. Die Smart Mock-Anleitung zeigt, wie die schema-bewusste Generierung hier ansetzt.
Sollte ich Cloud Mock oder ein Headless Mock Tool verwenden?
Cloud Mock eignet sich für Teams, die einen gehosteten, wartungsfreien Endpunkt wünschen, der an ihr API-Design gebunden ist. Wenn Sie Mocks benötigen, die in einen automatisierten Build ohne GUI eingebettet sind, vergleicht die Übersicht über Headless Mock Tools die Optionen und wo jede einzelne passt. Die OpenAPI Initiative-Spezifikation ist die Grundlage der meisten dieser Tools, daher zahlt sich eine saubere Spezifikation aus, welchen Weg Sie auch immer wählen.
Zusammenfassung
Ein Mock, der nur auf Ihrem Laptop existiert, entblockiert genau eine Person. Cloud Mock verwandelt ihn in eine öffentliche mock.apidog.com-URL, gegen die Ihr gesamtes Team entwickeln kann, mit Token-Authentifizierung, wenn Sie ihn schützen müssen, und Locale-Steuerungen, wenn Ihre Daten für eine bestimmte Region realistisch aussehen sollen. Entwerfen Sie den Endpunkt, aktivieren Sie den Schalter, teilen Sie den Link, und das Frontend wartet nicht mehr auf das Backend. Laden Sie Apidog herunter, um Ihren ersten teilbaren Cloud Mock einzurichten, kostenlos und ohne Kreditkarte.