Die besten schlanken CLI-Tools für API-Mocking

Sie benötigen eine simulierte API, um dagegen zu entwickeln, und Sie benötigen sie in den nächsten dreißig Sekunden. Kein gehosteter Dienst, kein Docker Compose Stack, keine GUI zum Durchklicken. Nur ein Befehl, der eine Datei liest und anfängt, Antworten auf localhost bereitzustellen.

Das ist es, was ein schlanker Mock-Server leistet. Sie verweisen ihn auf eine OpenAPI-Spezifikation oder eine kleine Datendatei, führen einen Befehl aus und erhalten realistische Endpunkte, die Ihr Frontend oder Ihre Tests ansprechen können, während das echte Backend noch entwickelt wird. Die besten werden als einzelne Binärdatei oder als `npx`-fähiges Paket geliefert, starten in weniger als einer Sekunde und benötigen fast keine Konfiguration. Einige der schwereren Optionen hier laufen auf der JVM und können weitaus mehr; sie verdienen ihren Platz, wenn Sie fortgeschrittene Anfragenübereinstimmung oder zustandsbehaftetes Verhalten benötigen.

Dieser Leitfaden bewertet sechs CLI-Mocker danach, wie wenig sie von Ihnen verlangen. Er beginnt mit denen, die Sie ohne Installation ausführen können, behandelt dann die eigenständigen JVM-Server und schließt mit dem integrierten Weg über die Apidog CLI. Jeder Installationsbefehl und Mock-Befehl unten wurde anhand der offiziellen Dokumentation jedes Tools überprüft. Wenn Sie das breitere Feld jenseits der Kommandozeile erkunden möchten, deckt die Übersicht über die besten API-Mock-Tools auch GUI- und gehostete Optionen ab.

Was macht ein CLI-Mock-Tool „schlank“?

„Schlank“ bezieht sich auf Speicherbedarf und Reibung, nicht auf den Funktionsumfang. Wenn Sie diese Tools vergleichen, sollten Sie vier Dinge abwägen:

• Installationsgröße und Laufzeit. Ein reines Node-Paket, das Sie `npx`en können, wiegt ein paar Megabyte. Ein eigenständiger JVM-Server ist ein 20MB+ großes Jar, das eine Java-Laufzeitumgebung benötigt. Beides ist gültig; sie liegen an verschiedenen Enden dieser Liste.
• Startgeschwindigkeit. Ein guter Mock-Server läuft, bevor Sie zu Ihrem Editor zurückgewechselt haben. Node-basierte Tools starten in deutlich unter einer Sekunde kalt.
• Konfiguration bis zur ersten Antwort. Können Sie mit einer Datei und einem Befehl von null zu einem aktiven Endpunkt gelangen? Die leichtesten Tools sagen ja.
• Terminal-fokussiert. Kein Konto, kein Dashboard, kein GUI-Schritt im Prozess. Das Tool liest eine Datei und stellt sie bereit, und es passt in ein Shell-Skript oder einen CI-Job.

Die Tools sind zuerst nach den kleinsten und schnellsten geordnet. Prism, Mockoon CLI und json-server sind diejenigen, die Sie mit `npx` und ohne globale Installation ausführen können.

Prism (Stoplight)

Prism verwandelt eine OpenAPI-Datei mit einem Befehl in einen Live-Mock-Server. Wenn Sie bereits eine Spezifikation haben, ist dies der Mock mit dem geringsten Aufwand auf dieser Liste; er liest Ihre `paths`, `examples` und Schemata und liefert dazu passende Antworten.

npx @stoplight/prism-cli mock ./openapi.yaml

Das startet einen Server auf `http://127.0.0.1:4010` mit jeder Operation in Ihrer Spezifikation, die angeschlossen ist. Prism gibt das von Ihnen definierte `example` für eine Antwort zurück oder generiert eine gültige Zufallsantwort aus dem Schema, falls Sie keines definiert haben. Es validiert auch eingehende Anfragen anhand der Spezifikation, sodass ein fehlerhafter Aufruf eine korrekte `422` erhält, anstatt stillschweigend durchgelassen zu werden. Für eine globale Installation verwenden Sie `npm install -g @stoplight/prism-cli` und lassen Sie das `npx` weg.

Am besten für: Spezifikations-zentrierte Teams, die möchten, dass der Mock dem Vertrag treu bleibt. Prism ist Apache-2.0-lizenziert und unterstützt OpenAPI 3.1, 3.0, 2.0 und Postman-Sammlungen.

Einschränkungen: Prism ist zustandslos. Ein `POST` speichert nichts dauerhaft, daher simuliert es keinen Erstellungs-dann-Lese-Workflow. Der Mock ist nur so gut wie Ihre Spezifikation; dürftige Beispiele bedeuten dürftige Antworten. Für vertragstreues Mocking ist das genau der Punkt, und es passt gut zum Workflow der REST-API-Mocking-Tools.

Mockoon CLI

Mockoon CLI führt eine Mock-API 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 ./mockoon-env.json --port 3000

Verweisen Sie `--data` auf eine Mockoon-Umgebungsdatei oder eine OpenAPI JSON/YAML-Datei, und es stellt sofort bereit. Wenn die Datendatei von einer älteren Mockoon-Version stammt, migriert die CLI sie im Speicher, ohne das Original zu berühren. Installieren Sie es global mit `npm install -g @mockoon/cli`, wenn Sie einen persistenten `mockoon-cli`-Befehl bevorzugen.

Am besten für: Teams, die Mocks in einer GUI entwerfen, aber headless ausführen möchten. Es ist MIT-lizenziert und verfügt über ein offizielles Docker-Image für Deployments.

Einschränkungen: Die komplexesten Routen werden in der Desktop-App erstellt, daher ist das manuelle Bearbeiten der JSON-Umgebungsdatei umständlich. Wenn Sie überhaupt keine Begleit-App wünschen, halten Prism oder json-server alles in einer einzigen Datei, die Sie manuell schreiben.

json-server

json-server ist die schnellste Möglichkeit, eine REST-API zu simulieren, wenn Sie noch keine Spezifikation haben. Sie schreiben eine einfache JSON-Datei, die Ihre Daten beschreibt, und es generiert eine vollständige REST-API darum herum, komplett mit `GET`, `POST`, `PUT`, `PATCH` und `DELETE`.

echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
npx json-server db.json

Das stellt `http://localhost:3000/posts` mit echtem CRUD bereit. Ein `POST` an `/posts` fügt tatsächlich einen Datensatz hinzu und schreibt ihn zurück in `db.json`, sodass Sie zustandsbehaftetes Verhalten kostenlos erhalten, was Prism und WireMock Ihnen nicht von Haus aus bieten. Sie erhalten auch Filterung, Sortierung und Paginierung über Abfrageparameter. Die aktuelle 1.x-Linie überwacht die Datei und lädt sie standardmäßig bei Änderungen neu; installieren Sie global mit `npm install -g json-server`, wenn Sie es immer in Ihrem `PATH` haben möchten.

Am besten für: Frontend-Entwickler, die in einer Minute ein funktionierendes REST-Backend benötigen, bevor die eigentliche API existiert. Es ist MIT-lizenziert und eine der schlanken Mock-Server-Optionen für eine RESTful API, die keine Spezifikation benötigt.

Einschränkungen: Es geht von einer Ressourcen-orientierten REST-Struktur aus. Stark angepasste Routen, Nicht-REST-Endpunkte oder strikte Header-Übereinstimmungen liegen außerhalb dessen, was es sauber erledigt. Es ist ein Prototyping-Tool, kein Vertragsvalidator.

MockServer

MockServer ist das Schwergewicht für präzise Anfragenübereinstimmung. Wo die oben genannten Tools eine Spezifikation oder eine Datendatei bereitstellen, ermöglicht Ihnen MockServer das Definieren von Erwartungen: Eine Anfrage nach Methode, Pfad, Header, Query oder Body abgleichen, dann genau die gewünschte Antwort zurückgeben, einschließlich Verzögerungen und Fehlern zum Testen von Timeouts und Fehlerbehandlung.

java -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080

Das startet MockServer auf Port `1080`. Sie senden dann Erwartungen an seine REST-API, um das Verhalten zu konfigurieren, oder steuern es programmatisch. Node-Benutzer können das rohe Jar überspringen und den offiziellen Wrapper verwenden:

npm install mockserver-node

const mockserver = require('mockserver-node');
mockserver.start_mockserver({ serverPort: 1080 });

Am besten für: Integrationstests, die eine feinkörnige Kontrolle darüber benötigen, wie eine Anfrage aussehen muss und wie der Mock antwortet. Es ist Apache-2.0-lizenziert und unterstützt HTTP, HTTPS und mehr auf einem einzigen Port.

Einschränkungen: Es ist ein JVM-Server, daher ist er schwerfälliger und langsamer zu starten als die Node-Tools, und die Erwartungseinrichtung ist ausführlicher als das Verweisen auf eine Spezifikation. Wenn Sie nur eine Spezifikation bereitgestellt benötigen, ist das überdimensioniert; wenn Sie es überfordern, zeigt der Vergleich der MockServer-Alternativen die Kompromisse auf.

WireMock (eigenständig)

WireMock ist der andere etablierte JVM-Mock-Server, beliebt in der Java- und JVM-Testwelt. Sein eigenständiges Jar führt dieselbe Engine aus, die Sie in einen JUnit-Test einbetten würden, sodass ein Mock, den Sie in der lokalen Entwicklung erstellen, direkt in Ihre Testsuite übernommen wird.

java -jar wiremock-standalone.jar --port 8080

Das stellt auf Port `8080` bereit. WireMock liest Stub-Mappings aus einem `mappings/`-Verzeichnis oder seiner JSON-API, und es kann auch echten Traffic aufzeichnen und als Stubs wiedergeben, was praktisch ist, wenn Sie eine Drittanbieter-API mocken, die Sie nicht kontrollieren. Es gibt ein offizielles `wiremock/wiremock` Docker-Image für CI.

Am besten für: JVM-Teams, die eine Mocking-Engine gemeinsam zwischen lokaler Entwicklung und ihrer Testsuite nutzen möchten, plus Aufzeichnung und Wiedergabe. Es ist Apache-2.0-lizenziert.

Einschränkungen: Wie MockServer benötigt es eine Java-Laufzeitumgebung und startet langsamer als die Node-Optionen. Sein Stub-Mapping-JSON ist mächtig, aber aufwendiger zu lernen als ein Ein-Datei-Daten-Mock. Wenn Sie von der JavaScript-Seite kommen, zeigt der Vergleich der Mock Service Worker (MSW)-Alternativen, wo WireMock im Vergleich zu Browser-fokussiertem Mocking steht.

Apidog CLI

Die oben genannten Tools lösen jeweils einen Teilbereich des Mockings. Apidog wählt den integrierten Weg: Ihr API-Design, der Mock, Ihre Tests und Ihre Dokumentation leben in einem Projekt, und die Apidog CLI steuert dieses Projekt vom Terminal aus. Apidog ist nicht Open Source; es ist ein kommerzielles Produkt mit einem kostenlosen Tarif. Aber dieser kostenlose Tarif plus die CLI bietet Ihnen eine Alternative zum Zusammenfügen separater Mock-Server, Test-Runner und Spezifikationstools.

Apidog generiert automatisch einen intelligenten Mock aus jedem von Ihnen definierten Endpunkt, mit Antworten, die den Feldtypen und der Benennung Ihres Schemas folgen, sodass ein `phone`-Feld eine plausible Telefonnummer anstelle einer zufälligen Zeichenkette zurückgibt. Wenn Sie eine spezifische Antwort für eine spezifische Anfrage benötigen, fügen Sie eine Mock-Erwartung hinzu. Die CLI verwaltet diese Mock-Ressourcen als Teil des Projekts:

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog mock --help

Die Befehlsgruppe `mock` arbeitet mit den Mock-Erwartungen Ihres Projekts aus Skripten und CI, neben Befehlsgruppen für Endpunkte, Schemata, Umgebungen und Testläufe. Die Ausgabe ist strukturiertes JSON mit einem `agentHints.nextSteps`-Feld, was es sowohl für KI-Agenten als auch für Menschen nutzbar macht. Die vollständige Befehlsoberfläche wird in der vollständigen Anleitung zur Apidog CLI behandelt.

Am besten für: Teams, die den Mock, die Spezifikation und die Tests lieber an einem Ort behalten, als drei separate Tools auszuführen. Laden Sie Apidog herunter, um den integrierten Mock-Server und die CLI in Ihrem eigenen Projekt auszuprobieren.

Einschränkungen: Es ist eine Plattform, keine einzige Binärdatei für einen bestimmten Zweck, daher erfordert es ein Projekt und eine Anmeldung, wo json-server nichts verlangt. Wenn Sie nur einen temporären Mock aus einer Datei benötigen, gewinnt ein schlankeres Tool; wenn Sie Ihre API bereits in Apidog entwerfen, ist der Mock bereits vorhanden.

Wie man wählt

Wählen Sie das Tool passend zu dem, was Sie bereits haben. Wenn Sie eine OpenAPI-Spezifikation haben, stellen Prism oder Mockoon CLI diese direkt bereit. Wenn Sie noch nichts haben, erfindet json-server eine API aus einer JSON-Datei. Wenn Sie eine genaue Anfragenübereinstimmung benötigen, greifen Sie zu MockServer oder WireMock. Wenn Sie möchten, dass der Mock neben Ihrem Design und Ihren Tests lebt, verwenden Sie Apidog.

Die grobe Regel: `npx`-Tools für Geschwindigkeit, JVM-Server für Übereinstimmungstiefe, Apidog, wenn Sie einen Workflow anstelle mehrerer möchten. Wenn Sie noch überlegen, ob Sie überhaupt mocken sollen, behandelt die exemplarische Darstellung der API-Mocking-Anwendungsfälle, wann es sich auszahlt.

Zusammenfassung

Schlankes Mocking lässt sich auf eine Frage reduzieren: Was haben Sie bereits, um das Tool zu füttern? Eine Spezifikation geht an Prism oder Mockoon CLI. Ein leeres Blatt geht an json-server. Strenge Übereinstimmung geht an MockServer oder WireMock. Und wenn Sie lieber nicht mehrere Tools ausführen und miteinander verbinden möchten, hält Apidog den Mock neben Design und Tests, gesteuert über dieselbe CLI, die Sie ohnehin skripten würden.

Alle sechs laufen vom Terminal, passen in einen CI-Job und verschaffen Ihnen eine simulierte API in Sekunden statt Stunden. Wählen Sie das kleinste, das Ihren Fall abdeckt, und fügen Sie nur dann Gewicht hinzu, wenn Sie es tatsächlich benötigen. Um die integrierte Version zu sehen, laden Sie Apidog herunter und generieren Sie einen Mock-Server aus Ihrem API-Design in einem Schritt.