Service-Einstellungen

Jeder Service in einer Simulation hat eigene Einstellungen: wohin er weiterleitet, was er zwischenspeichert, was er validiert und wie seine Spec bedient wird. Sie liegen in der Seitenleiste unter Service-Konfiguration.

Eine Seite pro Service

Die Seite konfiguriert einen Service auf einmal. Wähle ihn im Dropdown oben; das Symbol zeigt, ob es eine Menge statischer Endpunkte oder eine OpenAPI-Spec ist.

Beide Arten teilen sich den Großteil der Seite. Upstream, Cache und YAML gelten für jeden Service; Validierung und Spec-Optionen gibt es nur für OpenAPI-Services, weil beide eine Spec brauchen. Ein statischer Service hat auch keinen Mount zu bearbeiten: Sein Präfix kommt aus dem ersten Pfadsegment seiner Endpunkte.

Das Menü in der Ecke verwaltet den Service selbst: Datei ersetzen tauscht die Spec, Aus Katalog zurücksetzen stellt eine Katalog-Spec wieder her, und Service löschen entfernt ihn. Das Löschen eines statischen Service löscht jeden Endpunkt unter seinem Präfix.

Mount-Pfad

Neben dem Dropdown zeigt ein OpenAPI-Service seinen Mount als /<mount>/*, direkt editierbar. Kleinbuchstaben, Ziffern, -, _ und /, kein Schrägstrich am Anfang oder Ende, bis zu 32 Zeichen; ein Mount, den ein anderer Service hält, wird abgelehnt. Eine Änderung verschiebt jeden Endpunkt des Service auf das neue Präfix, Aufrufer müssen also mitziehen.

Upstream

Schalte An einen Upstream proxen ein und Anfragen erreichen zuerst dein echtes Backend; die Simulation antwortet nur, wenn das Backend es nicht tut.

Wer wann antwortet:

• Der Upstream antwortet erfolgreich: Seine Antwort geht unverändert an den Aufrufer.
• Der Upstream ist nicht erreichbar, läuft in den Timeout oder liefert einen Fehlerstatus: Stattdessen antwortet der generierte Mock.
• Status, die auf Bei Upstream-Status fehlschlagen passen, überspringen den Fallback und erreichen den Aufrufer unverändert. Standard ist 400-499 außer 401 und 403: Dein eigener Bad Request bleibt sichtbar, fehlende Zugangsdaten fallen auf den Mock zurück. Auf den Response-Body matchen verfeinert eine Regel für Backends, die Fehlercodes in den Body schreiben.

Jede Antwort nennt ihre Quelle: Der Header X-Mockzilla-Source sagt upstream, generated, cache oder replay.

Hinzugefügte Header werden an jede weitergeleitete Anfrage gehängt; ein Auth-Token oder eine Tenant-ID gehört hierhin statt in jeden Client.

Sticky-Upstream-Routing hilft, wenn ein Fallback mitten im Ablauf passiert ist: Nachdem ein Aufrufer eine generierte Antwort bekommen hat, gehen seine weiteren Anfragen für die eingestellte Dauer direkt an Mocks, damit eine Anfrage echten und generierten Zustand nicht mischt.

Der Timeout bestimmt, wie lange auf das Backend gewartet wird, 5s wenn nicht geändert.

Der hier gesetzte Upstream gilt für den ganzen Service. Ein einzelner Endpunkt kann ihn mit einer anderen URL überschreiben: Öffne den Endpunkt und wähle dort den Tab Upstream. Alle anderen Endpunkte nutzen weiter den Service-Upstream.

Siehe Endpunkte und statische Antworten.

Cache

GET-Antworten zwischenspeichern liefert für wiederholte GET-Anfragen wieder die erste Antwort, statt jedes Mal neu zu generieren oder abzurufen. Nur GET-Anfragen werden zwischengespeichert, und bei Wiederholungen gewinnt die zwischengespeicherte Antwort gegen den Upstream. Schalte es ein, wenn Consumer erneut abrufen und wechselnde Daten nur Rauschen wären.

Validierung

Eine OpenAPI-Spec ist ein Vertrag, und der Tab Validierung lässt die Simulation ihn durchsetzen.

• Anfragen validieren prüft eingehende Bodies, Query und Pfadparameter gegen die Spec. Eine Anfrage, die nicht passt, bekommt einen 400 mit Details und erreicht den Upstream nie. Das ist der Schalter beim Bauen eines Clients: Der Mock meldet einen kaputten Aufruf in dem Moment, in dem du ihn machst.
• Antworten validieren prüft Antworten auf dem Weg nach draußen; eine Antwort, die nicht zur Spec passt, wird ein 500 mit Details. Für generierte Antworten ist das selten nötig. Es lohnt sich mit einem Upstream: Jede echte Antwort wird gegen die Spec geprüft, was die Simulation zu einem Contract-Test für den Service dahinter macht. Es fängt auch einen Kontextwert, der das Schema bricht, das er füllt.
• Ausführliche Fehlerdetails legt das vollständige Referenzschema in Fehler-Payloads; standardmäßig schlank.
• Validierungs-Timeout begrenzt einen einzelnen Validierungsaufruf, eine Sekunde wenn nicht geändert, damit ein bösartiges Schema keine Anfragen blockiert.

Spec-Optionen

Diese Optionen steuern, wie die Spec geladen und bedient wird. Sie zählen vor allem bei sehr großen Specs.

• Operationen lazy laden parst jede Operation erst bei ihrer ersten Anfrage statt alle beim Start. Schnellerer Start bei großen Specs, kaum Unterschied bei kleinen.
• Schema vereinfachen verschlankt übergroße Schemas und entfernt zusätzliche anyOf/oneOf/allOf-Zweige. Eingeschaltet zeigt es Optionale Properties begrenzen: begrenze, wie viele optionale Felder erzeugte Antworten behalten. Gleiche Min- und Max-Werte ergeben eine feste Anzahl; ein Bereich wählt zufällig.

Siehe OpenAPI-Spec hochladen und aktualisieren dafür, wann eine Spec schwer genug ist, um sie zu brauchen.

Der YAML-Tab

Dieselbe Konfiguration wie in den anderen Tabs, im rohen YAML-Format der Engine. Vorerst schreibgeschützt; nutze ihn, um genau zu sehen, was die deployte Simulation erhält.