# REST-API-Qualität in KI-gestützter Entwicklung sichern

> Ein kurzer Leitfaden, wie Ressourcenmodelle, HTTP-Verhalten, Fehlerbehandlung, Autorisierung, Sicherheit und Vertragsentscheidungen bei REST-APIs mit KI in Prompt, Review und Auslieferungsprüfungen erhalten bleiben.

> 💡 **Kurzfassung**
> - **Vor dem Coding:** Lassen Sie den Agenten Geschäftsprozess, Ressourcenmodell, Zugriffsgrenzen, Fehlerverhalten und Vertragsänderung erklären. Fehlende Informationen darf er nicht durch Annahmen ersetzen.
> - **Im Review:** Prüfen Sie HTTP-Methoden, Wiederholungsverhalten, Datensatz-Eigentümerschaft, Fehlervertrag, zu breite Datenzugriffe und Abwärtskompatibilität unabhängig.
> - **Vor der Auslieferung:** Erzwingen Sie OpenAPI-Validierung, Vertrags- und Breaking-Change-Tests, negative Autorisierungstests und abgestimmte Dokumentation in der Pipeline. Geschäftsentscheidungen bleiben menschliche Verantwortung.

2021 veröffentlichte ich auf dieser Website eine sieben Teile umfassende REST-Reihe: REST-Komponenten, Design-Details, URI-Struktur, Fehlerbehandlung, Authentifizierung, Sicherheit und Dokumentation. Sechs dieser Artikel hatten auch englische Ausgaben.

Die meisten Grundsätze gelten weiterhin. Ich ziehe die Reihe nicht zurück, weil sie falsch geworden wäre. Sie entstand für eine Arbeitsweise, bei der Entwickler jedes Thema nacheinander studierten, die REST-Entscheidungen lernten und anschließend den Code schrieben.

Heute beschreiben viele Entwickler einem KI-Coding-Agenten in wenigen Sätzen, was sie brauchen, und arbeiten mit dem resultierenden Code weiter. Die alten Artikel getrennt zu lassen, würde solide Regeln in einem weniger üblichen Lernpfad einschließen. Deshalb ersetze ich sie durch diesen Artikel: die Grundsätze dort einsetzen, wo sie in KI-gestützter API-Arbeit entscheidend sind – im ersten Prompt, im Code Review und in Auslieferungsprüfungen.

## Warum ist ein REST-API-Prompt unvollständig?

Bitten Sie einen Agenten, „eine CRUD-API für Kundendaten“ zu schreiben, können Sie in Minuten funktionierende Endpunkte erhalten. Funktionierender Code beantwortet jedoch nicht:

- Darf ein Kundendatensatz physisch gelöscht, archiviert oder anonymisiert werden?
- Was geschieht, wenn dieselbe Löschanfrage zweimal eintrifft?
- Unter welchen Bedingungen darf ein Nutzer den Kundendatensatz eines anderen sehen?
- Wen betrifft es, wenn sich eine vom mobilen Client verwendete Antwort ändert?
- Kann ein Client nach einem Fehler sicher erneut versuchen?

Der erste Schritt zu REST-Qualität besteht darin, diese Entscheidungen zu treffen. URIs und Anwendungscode kommen danach. Ein Agent füllt ausgelassene Entscheidungen oft mit plausibel wirkenden Annahmen. Eine technische Präferenz wird dann unbemerkt zu einer Geschäftsentscheidung über Aufbewahrung, Zugriff oder Integration.

## Eine Anweisung vor dem ersten Code

```text
Do not write code yet. First, for this API change:

1. Explain the business process, the resource owner, and the expected outcome.
2. List the resources, their relationships, and the URI structure you propose.
3. For every endpoint, state the HTTP method, its side effects, and what happens
   if the same request is repeated.
4. Define successful responses, error conditions, and what the client should do
   for each error.
5. Show authentication, authorization, role, tenant, and record-ownership checks
   separately.
6. List input validation, returned fields, request size, rate limits, logging,
   and sensitive-data risks.
7. Show the proposed difference from the current OpenAPI contract and any
   backward-compatibility risk.
8. If you propose a new database, cache, queue, or service, explain the concrete
   need it addresses and its operating cost.

If information is missing, do not make assumptions. List the questions and wait.
```

Diese Anweisung lehrt den Agenten nicht REST. Sie macht sichtbar, welche Entscheidungen vor dem Code getroffen werden müssen. Zugleich verhindert sie, dass eine Lösch- oder Aufbewahrungsentscheidung, die dem Product Owner gehört, als technische Annahme umgesetzt wird.

## Frühere REST-Grundsätze mit KI bewahren

| Grundsatz | Dem Agenten sagen | Im Review prüfen |
|---|---|---|
| **Komponenten und Architektur** | Keine Datenbank, keinen Cache, keine Queue, keinen Dienst und kein Framework ohne nachgewiesenen Bedarf hinzufügen. Das gelöste Problem und die Betriebskosten nennen. | Beantwortet jede Abhängigkeit einen realen Last-, Zuverlässigkeits- oder Integrationsbedarf? Kann das Team sie betreiben? |
| **Ressourcen und URI-Design** | URIs aus dauerhaften Ressourcen der Geschäftsdomäne ableiten. Bestehende Regeln für Namen, Plural, Kleinschreibung und Unterressourcen konsistent anwenden. | Machen URI und HTTP-Methode die Operation zusammen klar? Wird dieselbe Ressource anderswo anders genannt? |
| **HTTP-Methoden** | Für jeden Endpunkt sicheres, idempotentes und wiederholbares Verhalten nennen. Keine Arbeit mit Seiteneffekten hinter `GET` verstecken. | Kann eine wiederholte Anfrage dasselbe Ergebnis doppelt erzeugen? Ändert `GET` den Zustand? Entsprechen `PUT`, `PATCH` und `DELETE` dem Vertrag? [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html){.dofollow} definiert diese Semantik. |
| **Fehlerbehandlung** | Ein maschinenlesbares Fehlerformat für alle Endpunkte verwenden; Statuscode, sichere Nachricht, Feldfehler, Problemcode und Request-ID definieren. | Sind `401`, `403`, `404`, `422`, `429` und `5xx` unterscheidbar? Geben sie Stacktraces oder sensible Informationen preis? Weiß der Client, was als Nächstes zu tun ist? [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457.html){.dofollow} beschreibt ein gemeinsames Problemantwortformat. |
| **Identität und Autorisierung** | Authentifizierung, funktionale Autorisierung und Datensatz-Eigentümerschaft getrennt entwerfen. Regeln zu Rolle, Geltungsbereich, Mandant und Objekteigentum je Endpunkt nennen. | Kann ein Nutzer mit gültigem Token durch Ändern einer ID auf einen fremden Nutzer- oder Mandantendatensatz zugreifen? Ist ein Admin-Endpunkt für gewöhnliche Nutzer offen? |
| **Sicherheit und Missbrauch** | Jede Eingabe per Schema validieren. Schreibbare und zurückgegebene Felder explizit begrenzen. Anfragegröße, Rate Limits, Geheimnisse, Protokollierung und Missbrauchsszenarien behandeln. | Lassen sich geschützte Daten durch zusätzliche Felder ändern? Kommt mehr Daten zurück als nötig? Gibt es negative Autorisierungs-, Ressourcenverbrauchs- und sensible Workflow-Tests? Die [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/){.dofollow} sind ein brauchbarer Review-Ausgangspunkt. |
| **Vertrag und Dokumentation** | Den OpenAPI-Diff vor dem Anwendungscode vorbereiten. Anfrage-, Antwort-, Fehler-, Sicherheits- und Rate-Limit-Verhalten mit Beispielen definieren. | Entspricht der Code dem Vertrag? Bricht die Änderung bestehende Clients? Haben Dokumentation und veröffentlichter Vertrag dieselbe Version? [OpenAPI](https://spec.openapis.org/oas/latest.html){.dofollow} definiert das Format dieses gemeinsamen Vertrags. |

Ein enger HATEOAS-Grundsatz bleibt ebenfalls relevant: Ist die nächste gültige Aktion Teil des Geschäftsworkflows, darf die Antwort den Client nicht zum Raten zwingen. Links oder Aktionsmöglichkeiten müssen in KI-gestützter API-Arbeit eine explizite Vertragsentscheidung sein, nicht improvisiertes JSON.

Diese Tabelle kann als API-Entwicklungsregel dienen. Regeln für jede API-Arbeit gehören in dauerhafte Agent-Anweisungen des Repositories. Produkt- oder endpunktspezifische Entscheidungen gehören ins Arbeitsbriefing und in den OpenAPI-Vertrag.

## Anweisung für einen zweiten Agenten im Review

Den Agenten, der den Code schrieb, um Selbstprüfung zu bitten, kann helfen. Ein Agent im selben Kontext erkennt seine eigene Annahme aber möglicherweise nicht als Fehler. Review ist eine stärkere Kontrolle, wenn es eine getrennte Aufgabe und nach Möglichkeit ein eigener Agentenkontext ist.

```text
Review this API change as an independent reviewer. Do not change code yet.
Do not treat the implementing agent’s explanation as evidence; use the existing
OpenAPI contract, repository rules, and tests instead.

Check the following:
- Are the resource model and URIs consistent with the existing API?
- Are HTTP methods, side effects, and retry behaviour correct?
- Do success and error responses match the contract?
- Are authentication, functional authorization, tenant, and record-ownership
  checks implemented separately?
- Are inputs, writable fields, and returned data broader than necessary?
- Is there a contract change that could break existing clients?
- Alongside the successful flow, are there tests for negative authorization,
  validation, rate limits, and retries?

For every finding, state the affected endpoint, evidence, risk, and required test.
Do not make corrections until the review is approved.
```

Ziel ist nicht, Code-Stil zu korrigieren. Das Review soll finden, wo der Agent eine Geschäftsentscheidung missverstanden, REST-Verhalten gebrochen oder eine Sicherheitsgrenze übersprungen hat.

## Welche Fehler soll die Pipeline automatisch stoppen?

Prompt und Review allein reichen nicht. Gelangen wiederholbare Regeln nicht in die Pipeline, kann derselbe Fehler in der nächsten Änderung erneut auftreten. Mindestens diese vier Prüfungen sollten automatisiert sein:

1. Ist der OpenAPI-Vertrag gültig und mit der Anwendung abgestimmt?
2. Führt der Vertrags-Diff eine nicht abwärtskompatible Änderung ein?
3. Bestehen Vertrags-, negative Autorisierungs-, Validierungs- und Wiederholungstests?
4. Hat die veröffentlichte Dokumentation dieselbe Version wie der Vertrag?

Änderungen am Zugriffsmodell, Zahlungsverhalten, sensiblen Daten, der Datenlöschrichtlinie oder bestehenden Clients sollten zudem zur Freigabe durch eine benannte Person anhalten. Ein weiterer Agent, der „sieht gut aus“ sagt, übernimmt diese Entscheidungen nicht.

## Warum die alte Reihe in einen Artikel überführen?

Die alte Reihe sollte Entwicklern REST beibringen. Der aktuelle Bedarf besteht darin, dieses Wissen im KI-gestützten Entwicklungsfluss nicht verschwinden zu lassen.

Eine Kontrollsequenz ist darum nützlicher als sieben getrennte Artikel:

1. Geschäftsentscheidung treffen.
2. Den Agenten die fehlenden Entscheidungen offenlegen lassen.
3. Den Vertrag vor dem Code sehen.
4. Die Implementierung durch ein unabhängiges Review schicken.
5. Wiederholbare Regeln in der Pipeline verpflichtend machen.

Kann ein Team diese Kontrollen nicht in Prompts, Repository-Anweisungen und Pipeline sichtbar machen, hat es sein früheres REST-Wissen nicht in die neue Arbeitsweise übertragen. Ein Agent kann schnell Code schreiben. Menschen entscheiden weiterhin, was die API verspricht und welche Risiken sie nicht akzeptieren können.

## Quellen

- [OpenAPI Specification](https://spec.openapis.org/oas/latest.html){.dofollow}
- [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html){.dofollow}
- [RFC 9457: Problem Details for HTTP APIs](https://www.rfc-editor.org/rfc/rfc9457.html){.dofollow}
- [OWASP API Security Top 10, 2023](https://owasp.org/API-Security/editions/2023/en/0x11-t10/){.dofollow}

---

Language: German
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/de/rest-api-qualitaet-in-ki-gestuetzter-entwicklung-sichern