⭐ Das Mai-Release reduziert Einrichtungsaufwand nach Migrationen, stärkt Authentifizierungs-Sicherheit für Unternehmen und macht API-Debugging-Ausgaben vollständiger.
Wenn Teams API-Arbeit zwischen Tools verschieben, endet die Migration nicht beim Import. Danach müssen Basis-URLs stimmen, Umgebungen verbunden sein, generierter Code Authentifizierung enthalten und CI-Runner zu internen Sicherheitsregeln passen.
Apidog noch heute ausprobieren
Dieses Release adressiert genau diese Punkte: Postman-Importe erhalten intelligenteres Basis-URL-Mapping, Enterprise Policies starten mit Auth Security Controls, Spec-First-Projekte lassen sich ohne vorherige Git-Bindung testen, Runner kann ohne Root-Rechte laufen, generierter Anfragecode kann Authentifizierungsinformationen enthalten, und mehrere Probleme bei Sharing, Testsynchronisierung und Mock-Daten wurden behoben.
⭐ Neue Updates
📦 Postman-Daten mit intelligenterem Basis-URL-Mapping importieren
Beim Import aus Postman kann Apidog gemeinsame Basis-URLs erkennen und sie automatisch im Basis-URL-Feld des passenden Moduls in den Umgebungen eintragen.
Praktischer Ablauf:
- Postman Collection importieren oder den Postman-API-Import verwenden.
- Apidog erkennt, wenn Anfrage-URLs eine gemeinsame Basis-Adresse oder erkennbare Variable verwenden.
- Der erkannte Wert wird als Modul-Basis-URL in den relevanten Umgebungen gesetzt.
- Importierte Requests können schneller direkt ausgeführt werden.
| Vorher | Jetzt |
|---|---|
| Collections importieren | Postman-Dateien importieren oder Postman-API-Import nutzen |
| Anfrage-URLs manuell prüfen | Gemeinsame Basis-URLs werden erkannt, wenn möglich |
| Basis-URLs pro Umgebung nachtragen | Erkannte Werte werden im Modul-Basis-URL-Feld platziert |
| Defekte Requests vor Tests reparieren | Importierte Requests sind schneller ausführbar |
Das reduziert einen typischen Cleanup-Schritt nach der Postman-Migration: weniger manuelles Prüfen von URLs und weniger Nacharbeit pro Umgebung.
🛡️ Enterprise Policies startet mit Auth Security Controls
Apidog führt Enterprise Policies als Governance-Framework für Sicherheitskontrollen auf Organisationsebene ein. Der erste Bereich ist Auth Security.
Damit können Organisationsadministratoren Regeln für sensible Authentifizierungsfelder definieren. Ziel ist, Zugangsdaten nicht als rohe Werte in Auth-Konfigurationen zu speichern, sondern beispielsweise als Variablen oder Vault Secrets zu verwenden.
Bei Vault Secrets können Teams außerdem verhindern, dass Werte im Klartext in der Oberfläche angezeigt werden. Mitglieder können Secrets weiterhin für Requests referenzieren, ohne dass der Wert über UI-Anzeige oder Screen Sharing offengelegt wird.
🔒 Ergebnis: Authentifizierungsdaten lassen sich besser kontrollieren, ohne API-Debugging in einen separaten Sicherheitsprozess auszulagern.
📝 Spec-First-Modus ohne vorherige Git-Einrichtung nutzen
Spec-First-Projekte lassen sich jetzt erstellen, ohne vorher ein Git-Repository zu binden. Danach können Sie eine OpenAPI-Datei hinzufügen oder importieren.
So können Teams Spec-First-Workflows früher evaluieren:
- Spec-First-Projekt in Apidog erstellen.
- Noch kein Git-Repository binden.
- OpenAPI-Datei hinzufügen oder importieren.
- Feedback zum API-Design sammeln.
- Git-Workflow später einrichten, wenn Struktur und Prozess klar sind.
ℹ️ Nützlich für Teams, die OpenAPI-zentrierte Arbeit testen möchten, bevor Repository-Struktur und Review-Prozess final sind.
🔒 Runner als Nicht-Root-Benutzer ausführen
Runner unterstützt jetzt die Ausführung als Nicht-Root-Benutzer.
Das ist besonders relevant für Server-, Container- und CI/CD-Umgebungen, in denen Root-Prozesse vermieden oder durch Richtlinien blockiert werden.
Beispielhafter Einsatzkontext:
# Beispiel: Runner-Prozess unter einem dedizierten Benutzer starten
# Der konkrete Startbefehl hängt von Ihrer Runner-Konfiguration ab.
whoami
# apidog-runner
Damit lässt sich Runner mit geringerem Berechtigungsumfang betreiben, ohne den bestehenden Test-Workflow grundsätzlich umzubauen.
✅ Vorteil: bessere Anpassung an interne Sicherheitsanforderungen in CI/CD- und Container-Umgebungen.
🔐 Generierter Anfragecode kann Authentifizierungsinformationen enthalten
Beim Generieren von Anfragecode aus einer API-Anfrage kann Apidog nun die bereits konfigurierte Authentifizierung einbeziehen.
Das macht generierte Code-Snippets näher an einer direkt ausführbaren Anfrage. Statt Tokens, Header oder Auth-Parameter nachträglich manuell zu ergänzen, erhalten Entwickler vollständigere Beispiele.
Typische Anwendungsfälle:
- API-Aufruf schnell lokal überprüfen
- lauffähiges Beispiel mit Teamkollegen teilen
- Anfrage in ein anderes Debugging-Setup kopieren
- reproduzierbaren Beispielcode für Support oder Tests erzeugen
✅ Optimierungen
🧩 CLI-Skriptausführung ist stärker eingeschränkt
Die CLI erlaubt jetzt nur noch das Aufrufen von Skripten aus dem Verzeichnis „Externe Programme“.
Wenn Ihr Team CLI-Skripte in Automatisierung verwendet, prüfen Sie vorhandene Skriptpfade:
Vorher:
beliebiger Skriptpfad möglich
Jetzt:
Skripte müssen aus „Externe Programme“ aufgerufen werden
Das reduziert das Risiko versehentlicher oder zu breit gefasster Skriptausführung, während beabsichtigte externe Programm-Workflows weiterhin möglich bleiben.
📋 Kopierte cURL-Befehle enthalten mehr Anfragekonfiguration
Beim Kopieren von cURL aus Apidog enthält der generierte Befehl konfigurierte Header- und Body-Parameter zuverlässiger.
Das ist hilfreich, wenn Sie:
- Requests im Terminal reproduzieren
- Fehlerberichte mit ausführbaren Beispielen ergänzen
- API-Aufrufe mit anderen Entwicklern teilen
- Debugging außerhalb der App durchführen
Beispielstruktur:
curl -X POST "https://example.com/api/resource" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"name":"example"}'
Der kopierte Befehl entspricht damit eher der Anfrage, die in Apidog konfiguriert wurde.
🧪 Automatisierte Testschritte bleiben nach Methodenänderungen synchron
Wenn sich die Request-Methode eines Endpunkts ändert, zum Beispiel von GET zu POST, PUT oder einer anderen Methode, synchronisieren die zugehörigen automatisierten Testschritte die aktualisierte Konfiguration genauer.
Das reduziert Abweichungen zwischen API-Definition und Testausführung.
Praktischer Effekt:
Endpunkt vorher: GET /users
Endpunkt nachher: POST /users
Automatisierte Testschritte übernehmen die aktualisierte Methode zuverlässiger.
Dadurch werden Testergebnisse nach Endpunkt-Änderungen vertrauenswürdiger.
🎲 Zuverlässigere Mock-Datengenerierung
Dieses Release behebt mehrere Probleme bei der Mock-Datengenerierung, darunter:
- Multiplikatorregeln
-
arrayElements-Ausdrücke - Batch-Generierung
- Kombination von JavaScript-Generierung und Mock-Generierung
Für Frontend-Backend-Integration, große Testdatenmengen und automatisierte Tests sollte die Mock-Ausgabe stabiler und näher an den konfigurierten Regeln sein.
🐞 Bugfixes und kleinere Verbesserungen
Zusätzlich wurden mehrere Fehler und UX-Probleme behoben:
- Anforderungsparameter in freigegebener Dokumentation zeigen Standardbeispiele wieder korrekt an.
- Der Export eines Projekts mit nur Markdown-Dokumenten und ohne Endpunkte kann nicht mehr fehlschlagen.
- Mehrere Mock-Daten-Probleme wurden behoben, unter anderem Batch-Generierung, gleichzeitige JavaScript- und Mock-Generierung, Zahlenmultiplikatoren sowie
arrayElementsMin-/Max-Ausdrücke. - Feste Links in der Projektübersicht können nach dem Öffnen von Links aus verschiedenen Projekten keinen 500er-Fehler mehr verursachen.
- Ein UI-Fehler mit
Error: Cannot read properties of null (reading 'nullable')wurde behoben. - Ein Kontrastproblem bei ausgewählten Beispielnamen in freigegebener Dokumentation im hellen Design wurde behoben.
- Windows-Benutzer können den AI Agent Debugger wieder normal verwenden.
- Ein Formular-Daten-Body-Feld mit mehreren hochgeladenen Dateien zeigt nach Batch-Bearbeitung und Speichern nicht mehr nur eine Datei an.
🌟 Was das für den Workflow bedeutet
Das Mai-Release entfernt kleine, aber teure Reibungspunkte aus API-Workflows.
| Bereich | Was sich verbessert | Warum es wichtig ist |
|---|---|---|
| Postman-Migration | Gemeinsame Basis-URLs werden zugeordnet, wenn Apidog sie zuverlässig erkennen kann | Weniger manuelle Bereinigung nach Import und Umgebungskonfiguration |
| Runner-Bereitstellung | Runner kann als Nicht-Root-Benutzer ausgeführt werden | Bessere Anpassung an Server-, Container- und CI/CD-Richtlinien |
| Unternehmenssicherheit | Enterprise Policies startet mit Auth Security Controls | Weniger Offenlegung roher Zugangsdaten in Auth-Workflows |
| Spec-First-Workflows | Spec-First-Projekte benötigen keine Git-Bindung vor der Nutzung | Teams können OpenAPI-zentrierte Arbeit früher ausprobieren |
| Request-Sharing | Generierter Code und cURL-Ausgaben enthalten mehr Request-Konfiguration | Beispiele sind einfacher ausführbar, reproduzierbar und teilbar |
| Testen und Mocking | Testschritte synchronisieren genauer, Mock-Generierung ist stabiler | Weniger Zeit für Konfigurationsabweichungen und unerwartete Testdaten |
Der Fokus liegt nicht auf zusätzlicher Komplexität, sondern auf weniger Nacharbeit nach der Einrichtung: weniger manuelle Korrekturen, sicherere Standardeinstellungen und Ausgaben, die besser zu Ihrer bestehenden Konfiguration passen.
💬 Beteiligen Sie sich am Gespräch
Vernetzen Sie sich mit anderen API-Ingenieuren und dem Apidog-Team:
- Treten Sie unserer Discord-Community für Echtzeit-Diskussionen und Support bei.
- Nehmen Sie an unserer Slack-Community für technische Gespräche teil.
- Folgen Sie uns auf X (Twitter) für die neuesten Updates.
P.S. Alle Details finden Sie im Apidog Changelog.
Mit freundlichen Grüßen,
Das Apidog Team
Top comments (0)