Eine fehlgeschlagene API-Antwort sollte das Problem verständlich machen. Prüfen Sie sie aus Sicht von Kunden und Support. MIT SZENARIEN BEGINNEN Bereiten Sie in einer Testumgebung einen fehlenden Datensatz, einen ungültigen Parameter und einen vorübergehenden Ausfall vor. Notieren Sie jeweils den nächsten Nutzerschritt, etwa Eingabe korrigieren oder später erneut versuchen. Erstellen Sie dafür keine echten Bestellungen. GEMEINSAME STRUKTUR RFC 9457 definiert Problem Details für HTTP-APIs und den Medientyp application/problem+json. Dabei bezeichnet type die Problemart und detail den konkreten Vorfall. Clients müssen nicht für jeden Fehler eine neue Struktur erraten. ZIELGRUPPEN TRENNEN Kunden brauchen einen kurzen nächsten Schritt, Entwickler eine stabile Erkennung der Situation. Steuern Sie die Anwendung nicht allein über übersetzte Meldungstexte. Vereinbaren Sie öffentlich zulässige Angaben; Passwörter, Token, interne Abfragen und private Gespräche gehören nicht in Antworten. DEN GESAMTEN WEG PRÜFEN Speichern Sie ein unbedenkliches Antwortbeispiel und prüfen Sie die Darstellung. Macht ein Formular aus jedem Fehler versehentlich einen Erfolg? Findet der Support die Anfrage ohne Geheimnisse anzufordern? Legen Sie Verantwortliche und Abschlusskriterien fest. Nehmen Sie für die Website einer Domain aus dem Katalog neben Erfolgsabläufen auch Fehlerbeispiele ins Briefing auf. So klären Sie das Verhalten vor dem Start statt nach der ersten unverständlichen Supportanfrage. Bild: neue KI-Fotoillustration für diesen Artikel; konzeptionelle Szene, keine dokumentarische Aufnahme. Domain-Katalog: https://domainevery.com/de/domains Primärquellen: https://www.rfc-editor.org/rfc/rfc9457.html
