Beschreibung und Durchsetzung unterscheiden
Eine von den Werkzeugen unterstützte Spezifikationsversion festlegen. Parameter, Inhalte, Antworten und Sicherheitsanforderungen beschreiben. Anwendungen und Gateways müssen die beschriebenen Anforderungen weiterhin selbst durchsetzen.
| Element | Beschreibt | Zusätzliche Prüfung |
|---|---|---|
| Schema | Struktur und Datenbeschränkungen | Wirksame Validierung und Geschäftsregeln. |
| Dokumentierte Antwort | Erwarteten Status und Inhalt | Übereinstimmung realer Antworten. |
| Sicherheitsanforderung | Angegebenen Mechanismus und Rechte | Wirksame Zugriffskontrolle je Vorgang. |
| Beispiel | Einen Anwendungsfall | Konsistenz, keine Geheimnisse und Grenzfälle. |
Vor Weitergabe prüfen
- Pflichtfelder, Typen, Wertebereiche, Seitennavigation, Fehler und Inhaltstypen prüfen. Fiktive, schemakonforme Beispiele ohne Geheimnisse oder Kundendaten verwenden.
- Beschreibung mit kontrollierten Anfragen und Antworten vergleichen. Fehlende Nachweise, unzureichende Rechte und Kontentrennung testen.
- Externe Verweise und auflösende Werkzeuge prüfen. Öffentliche Beschreibung bereinigen und private Umgebungen und Vorgänge schützen.
Dokumentation dauerhaft pflegen
Änderungen vergleichen und Verantwortung festlegen. Generierte Clients und Beispiele können strukturell korrekt sein und dennoch Geschäftsregeln übersehen. Interaktive Konsolen brauchen geeignete Umgebungen, begrenzte Rechte und klare Kennzeichnung zustandsändernder Vorgänge.
Primärquellen
OpenAPI mit dem laufenden Dienst vergleichen.
Eine hilfreiche OpenAPI-Beschreibung enthält Fehlerantworten, Schemas und Beispiele, die Clients tatsächlich begegnen. Wenn Dokumentation und API voneinander abweichen, kann eine Integration in der Demo funktionieren, in der Produktion jedoch fehlschlagen.
- Erfolgs- und Fehlerfälle mit der Beschreibung vergleichen.
- Optionale Werte, Paginierung und Operationsbeschränkungen dokumentieren.
- Einen repräsentativen Client testen, bevor der Vertrag geändert wird.
Primärquelle: IETF RFC 9457 — Problem Details for HTTP APIs. Verwandte Methode: den praktischen Leitfaden lesen.
ZIP und TAR: Dateien innerhalb von Pfad- und Ressourcenlimits entpacken
Pfade, Links und entpackte Daten vor der Freigabe der Dateien prüfen.
- Entpacke in ein neues nicht öffentliches Verzeichnis mit minimalen Rechten. Lehne absolute Pfade, Verzeichnisaufstieg, unnötige Links und Spezialdateien ab. Prüfe aufgelöste Ziele und Kollisionen nach Regeln des Zielsystems einschließlich Großschreibung. Ein Textpräfix beweist keine Begrenzung.
- Setze Einzel- und Gesamtlimits für geschriebene Bytes, Einträge, Tiefe, Zeit und Prozessressourcen. Komprimierte oder deklarierte Größe genügt nicht. Verbiete unnötige verschachtelte Archive; sonst teile ein Gesamtbudget über alle Ebenen. Halte Bibliothek und Filter aktuell.
- Teste ../, absolute Pfade, Links, Duplikate und Budgetüberschreitung. Ein Abbruch lässt den Stapel unveröffentlicht und ersetzt keine vorhandenen Dateien. Prüfe Typen und Inhalte vor Freigabe; kontrolliere das Ziel beim Aufräumen.
Nachvollziehbarer Abnahmefall
Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.
Falldaten anzeigen
{
"compressed_mb": 2,
"expanded_mb": 600,
"aggregate_budget_mb": 100,
"first_files_valid": true,
"expected": "stop_on_actual_overrun_and_do_not_promote"
}Erwartete Entscheidung
Fiktives Beispiel: 2 MB komprimiert ergeben 600 MB bei einem Budget von 100 MB. Bei Überschreitung tatsächlich geschriebener Bytes stoppen und nichts veröffentlichen, auch wenn erste Dateien gültig wirken.
Python — tarfile extraction filters and further verification
Garantiert ein kleines Archiv oder ein Filter Sicherheit?
Nein. Kleine Archive können stark wachsen. Ergänze Ressourcenlimits, Pfadregeln und Prüfung der Ausgabedateien.
Primärquelle: Python — tarfile extraction filters and further verification. Verwandte Methode: den praktischen Leitfaden lesen.
API-Fehler: Typen, Status und Nachweise
Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.
Include errors in contract tests
A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.
- Replay existing clients against representative refusals.
- Check tolerance of unknown extensions and localised text.
- Document migration of a problem identity and actually observed use.
Explore problem types and eight fictional responses →
IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5