Sie benötigen eine gefälschte API, gegen die Sie entwickeln können. Das Backend ist noch nicht bereit, der Drittanbieterdienst ist ratenbegrenzt, oder Sie möchten einfach, dass Ihre Tests ohne Zugriff auf einen Live-Server ausgeführt werden. Die übliche Antwort ist ein Mock. Die Frage ist, wie man einen solchen aufsetzt.
Sie können sich durch eine GUI klicken, um Routen und vordefinierte Antworten zu definieren. Das ist einmalig in Ordnung. Aber ein Mock, den Sie manuell in einer Desktop-Anwendung erstellen, ist schwer zu reproduzieren, schwer zu versionieren und für CI oder einen KI-Code-Agenten unmöglich, eigenständig neu zu erstellen. Ein Mock, den Sie über die Befehlszeile definieren, ist anders. Es ist ein Befehl in einem Skript, ein Schritt in einer Pipeline, eine Zeile, die ein Agent ausführen kann. Was Sie tippen, kann eine Maschine auch tippen.
Dieser Leitfaden behandelt zwei Ansätze. Zuerst den allgemeinen Open-Source-Pfad: Single-Binary-Mock-Server, die Sie direkt aus einer Datei ausführen, sodass eine Spezifikation oder eine JSON-Datei mit einem Befehl zu einem Live-Endpunkt wird. Dann den Apidog CLI-Pfad, der anders funktioniert und es wert ist, in seinen eigenen Begriffen verstanden zu werden. Wenn Sie zuerst einen Überblick über die Optionen wünschen, bieten unsere Zusammenfassung der besten API-Mock-Tools und der Leitfaden zu REST API Mocking Tools beide eine breitere Perspektive.
Der allgemeine Weg: einen Mock-Server aus einer Datei starten
Der klassische CLI-Mock ist ein kleines Binärprogramm, das Sie auf eine Datei verweisen. Geben Sie ihm eine Spezifikation oder eine Datendatei, und es stellt einen echten HTTP-Endpunkt an einem lokalen Port bereit. Kein Projekt, kein Login, kein Konto. Diese Tools tun eines: Sie verwandeln eine Datei in eine gefälschte API, die Sie aufrufen können. Drei davon decken fast jeden Fall ab.
Prism: eine OpenAPI-Spezifikation bereitstellen
Wenn Sie bereits eine OpenAPI-Datei haben, ist Prism von Stoplight der Mock mit dem geringsten Aufwand, den Sie ausführen können. Es liest Ihre paths, Beispiele und Schemas und liefert dann Antworten, die dem Vertrag entsprechen.
npx @stoplight/prism-cli mock ./openapi.yaml
Das startet einen Server unter http://127.0.0.1:4010, wobei jede Operation in Ihrer Spezifikation eingerichtet ist. Prism gibt das example zurück, das Sie für eine Antwort definiert haben, oder generiert ein gültiges zufälliges Beispiel aus dem Schema, falls Sie es weggelassen haben. Es validiert auch eingehende Anfragen anhand der Spezifikation, sodass ein fehlerhafter Aufruf einen korrekten 422 statt eines stillen Durchlaufs erhält. Rufen Sie es auf, um zu prüfen, ob es aktiv ist:
curl http://127.0.0.1:4010/orders/123
Prism ist zustandslos, daher speichert ein POST nichts dauerhaft. Das ist der Punkt, wenn Sie möchten, dass der Mock dem Vertrag treu bleibt. Für eine globale Installation führen Sie npm install -g @stoplight/prism-cli aus und lassen das npx weg.
Mockoon CLI: eine Datendatei Headless ausführen
Mockoon CLI führt einen Mock aus einer Datendatei aus, entweder einer, die Sie aus der kostenlosen Mockoon Desktop-App exportiert haben, oder einer einfachen OpenAPI-Spezifikation. Die Desktop-App ermöglicht es Ihnen, Routen visuell zu erstellen; die CLI führt dieselbe Umgebung headless in CI oder auf einem Server aus.
npx @mockoon/cli start --data ./env.json
Verweisen Sie --data auf eine Mockoon-Umgebungsdatei oder eine OpenAPI JSON/YAML-Datei, und es wird sofort bereitgestellt, standardmäßig auf Port 3000. Fügen Sie --port hinzu, um dies zu ändern. Wenn die Datendatei von einer älteren Mockoon-Version stammt, migriert die CLI sie im Speicher, ohne die Originaldatei zu ändern. Installieren Sie es global mit npm install -g @mockoon/cli für einen dauerhaften mockoon-cli-Befehl. Dies ist eine gute Wahl, wenn Sie reichhaltigere, handoptimierte Routen wünschen, als eine reine Spezifikation bietet, und diese trotzdem ohne GUI ausführen möchten. Ein leichter Mock-Server für eine RESTful API findet hier oft seinen Platz.
json-server: eine REST-API aus JSON fälschen
Wenn Sie noch keine Spezifikation haben, ist json-server der schnellste Weg. Sie schreiben eine einfache JSON-Datei, die Ihre Daten beschreibt, und es baut eine vollständige REST-API darum herum auf.
npx json-server db.json
Angenommen, eine db.json mit einem posts-Array, stellt http://localhost:3000/posts mit echten GET, POST, PUT, PATCH und DELETE bereit. Ein POST fügt tatsächlich einen Datensatz hinzu und schreibt ihn zurück in die Datei, sodass Sie zustandsbehaftetes Verhalten kostenlos erhalten, was Prism Ihnen nicht bietet. Sie erhalten auch Filterung, Sortierung und Paginierung über Abfrageparameter. Installieren Sie es global mit npm install -g json-server, wenn Sie es immer in Ihrem PATH haben möchten.
Das ist der offene Weg. Jedes Tool ist ein einzelnes Binärprogramm, wird aus einer Datei ausgeführt und benötigt nichts anderes. Der Kompromiss ist, dass jedes Tool eine eigene Insel ist. Der Mock lebt getrennt von Ihrem echten Design, Ihren Tests und Ihrer Dokumentation, und Sie müssen die Dateien und die laufenden Prozesse selbst synchron halten. Wenn Sie eine exakte Anfragenabgleichung oder Wiederholung benötigen, gehen MockServer und WireMock tiefer, allerdings auf Kosten einer Java-Laufzeitumgebung.
Der Apidog CLI-Pfad: Spezifikation importieren, Erwartungen skripten
Apidog mockt anders, und wenn Sie das richtig verstehen, vermeiden Sie Verwirrung. Die apidog CLI startet keinen lokalen Mock-Server aus einer Datei. Es gibt kein apidog mock ./openapi.yaml. Stattdessen hostet Apidog den Mock für Sie, und die CLI ist die Methode, wie Sie ihm eine Spezifikation zuführen und benutzerdefinierte Antworten skripten.
Zuerst ein ehrlicher Hinweis. Apidog ist nicht Open Source; es ist ein kommerzielles Produkt mit einem kostenlosen Tarif. Was dieser kostenlose Tarif plus die CLI Ihnen bietet, ist ein integriertes Projekt, sodass der Mock, das Design und die Tests eine einzige Quelle der Wahrheit teilen, anstatt drei separater Dateien und drei separater Prozesse. Wenn ein Wegwerf-Mock aus einer Datei alles ist, was Sie brauchen, gewinnt ein leichteres Tool. Wenn Ihr Mock mit Ihrer tatsächlichen API im Einklang bleiben soll, während sie sich ändert, lesen Sie weiter.
Zuerst installieren und authentifizieren (der Apidog CLI-Installationsleitfaden behandelt die Token-Einrichtung):
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Eine Spezifikation importieren, um gehostete Smart Mocks zu erhalten
Der erste Schritt ist, Ihre API in ein Projekt zu bringen. Importieren Sie eine OpenAPI-Datei, und Apidog generiert automatisch eine Mock-URL für jeden Endpunkt.
apidog import --project <PROJECT_ID> --format openapi --file ./openapi.json
Hier unterscheidet sich Apidog von Prism und json-server. Sie starten keinen Server; der Import gibt Ihnen einen gehosteten Smart Mock für jede Operation. Smart Mock liest die Feldtypen und -namen Ihres Schemas, sodass ein email-Feld eine plausible E-Mail zurückgibt und ein createdAt einen echt aussehenden Zeitstempel zurückgibt, keine zufällige Zeichenfolge. apidog import akzeptiert auch Swagger 2.0-, Postman- und Apidog-Formate, sodass eine vorhandene Definition mit einem Befehl zu Live-Mocks wird.
Benutzerdefinierte Antworten mit apidog mock skripten
Automatisch generierte Mocks decken den allgemeinen Fall ab. Wenn Sie eine spezifische Antwort für eine spezifische Anfrage benötigen, z. B. eine 200 für eine Benutzer-ID und eine 404 für eine andere, fügen Sie eine Mock-Erwartung hinzu. Dies wird von der Befehlsgruppe apidog mock verwaltet, und es handelt sich um CRUD-Operationen auf diesen Erwartungen, nicht um einen Server, den Sie starten.
apidog mock --help
apidog mock list --project <PROJECT_ID>
apidog mock list --project <PROJECT_ID> --http-api-id <ENDPOINT_ID>
Die Auflistung gibt strukturiertes JSON zurück, sodass Sie es durch jq pipen können, um die ID einer Erwartung zu finden und diese dem nächsten Befehl zuzuführen. Um eine zu lesen, zu ändern oder zu entfernen:
apidog mock get --project <PROJECT_ID>
apidog mock update --project <PROJECT_ID> --file ./mock.json
apidog mock delete --project <PROJECT_ID>
Die Unterbefehle create und update verwenden eine --file, die die Erwartung beschreibt. Holen Sie sich die richtige Form, bevor Sie sie schreiben, dies wird als Nächstes behandelt.
Die Erwartungsdatei vor dem Schreiben validieren
Erraten Sie das JSON nicht manuell. Die CLI liefert ein Schema für jede Schreiboperation, sodass Sie die Form abrufen, ausfüllen und validieren können, bevor die eigentliche Schreiboperation erfolgt. Eine falsch formatierte Erwartung schlägt schnell fehl, anstatt stillschweigend zu landen.
apidog cli-schema get mock-create
apidog cli-schema validate mock-create --file ./mock.json
apidog mock create --project <PROJECT_ID> --file ./mock.json
Rufen Sie das Schema ab, schreiben Sie Ihre mock.json passend, validieren Sie es und erstellen Sie es dann. Wenn die Validierung einen Exit-Code ungleich Null zurückgibt, stoppt die Pipeline, bevor eine fehlerhafte Datei Ihr Projekt erreicht. Führen Sie dieselben drei Schritte für Updates mit dem Schema-Schlüssel mock-update aus. Jeder Befehl gibt JSON mit einem agentHints.nextSteps-Block zurück, der Ihnen oder einem Agenten mitteilt, was als Nächstes ausgeführt werden soll, was diesen Workflow für KI-Coding-Tools und nicht nur für Menschen nutzbar macht. Der vollständige Apidog CLI-Leitfaden beschreibt die restlichen Befehlsgruppen.
Einbindung in CI
Beide Ansätze passen in eine Pipeline, da jeder Befehl einen Exit-Code und eine Textausgabe hat. Ein serverbasierter Mock und ein Integrationstest im selben Job könnten so aussehen:
# Prism im Hintergrund starten, dann Tests dagegen ausführen
npx @stoplight/prism-cli mock ./openapi.yaml &
PRISM_PID=$!
npm test
kill $PRISM_PID
Der Apidog-Workflow ist anders strukturiert: Es gibt keinen lokalen Prozess zum Starten und Stoppen, da der Mock gehostet wird. Sie validieren und wenden Erwartungen als Einrichtungsschritt an, und Ihre Tests greifen direkt auf die gehostete Mock-URL zu.
# sicherstellen, dass die Erwartung wohlgeformt ist, dann anwenden
apidog cli-schema validate mock-create --file ./mock.json
apidog mock create --project <PROJECT_ID> --file ./mock.json
So oder so klickt niemand auf eine Schaltfläche. Das ist der Hauptgrund, warum man von der CLI aus mockt: Ein Spec-First-Team, ein CI-Job und ein KI-Agent können alle dieselbe gefälschte API mit denselben Befehlen aufsetzen.
Häufige Fallstricke
Erwartung, dass apidog mock einen Server startet. Das wird nicht passieren. Es gibt kein apidog mock start, apidog mock serve oder apidog mock ./file.yaml. Sie apidog import eine Spezifikation, um gehostete Mocks zu erhalten, und apidog mock verwaltet die benutzerdefinierten Erwartungen darauf. Wenn Sie einen lokalen Prozess starten möchten, den Sie aus einer Datei starten, dann sind das Prism, Mockoon CLI oder json-server.
Überspringen des Schema-Schritts bei einem Schreibvorgang. apidog mock create und update verwenden eine --file, und eine falsche Form schlägt fehl oder schreibt etwas, das Sie nicht beabsichtigt haben. Führen Sie immer zuerst cli-schema get und cli-schema validate aus. Das sind zwei zusätzliche Befehle, die Ihnen eine Debugging-Sitzung ersparen.
Prism sieht leer aus, weil Ihre Spezifikation dünn ist. Der Mock von Prism ist nur so gut wie Ihre Beispiele. Wenn eine Antwort kein example und ein vages Schema hat, erhalten Sie vage Daten. Fügen Sie Beispiele zur Spezifikation hinzu, und der Mock wird präziser.
Zustandsbehaftete Erwartungen von einem zustandslosen Tool. Die Vertrags-Mocks von Prism und Apidog speichern keine Schreibvorgänge. Wenn Sie ein POST und dann ein GET benötigen, um den neuen Datensatz zurückzugeben, greifen Sie auf json-server oder eine Apidog-Erwartung zurück, die die gewünschte Form zurückgibt.
Zusammenfassung
Das Mocking über die CLI verwandelt eine klickintensive Aufgabe in Befehle, die Sie skripten, überprüfen und an CI oder einen Agenten übergeben können. Der offene Weg bietet Ihnen Single-Binary-Server, die Sie aus einer Datei ausführen: Prism für eine OpenAPI-Spezifikation, Mockoon CLI für eine Headless-Datendatei, json-server für eine sofortige REST-API aus JSON. Der Apidog-Weg funktioniert andersherum; Sie importieren eine Spezifikation einmal, um gehostete Smart Mocks zu erhalten, und skripten dann benutzerdefinierte Antworten mit apidog mock und der cli-schema-Validierungswächter.
Wählen Sie basierend darauf, was Sie bereits haben und wo der Mock leben soll. Wenn Sie einen Wegwerf-Server aus einer Datei wünschen, sind die Open-Source-Tools perfekt. Wenn der Mock mit Ihrem Design und Ihren Tests in einem Projekt im Einklang bleiben soll, laden Sie Apidog herunter, installieren Sie die CLI und richten Sie Ihre Mocks ein, ohne eine Maus zu berühren.