Rate-Limiting Submission API

Warum?

Um Überlastungen von Zustelldienst und nachgelagerten Systmen zu vermeiden, ist ein Rate-Limiting zu implementieren.

Zur Darstellung der Rate-Limits würden wir gerne die üblichen RateLimit-Header nutzen und uns dabei am IETF-Draft der Italienischen Kolleg:innen orientieren: https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers

Beispiel:

$ curl https://routing-api.fit-connect.fitko.net/status
> HTTP/2 200
> RateLimit-Limit: 5000
> RateLimit-Remaining: 4966
> RateLimit-Reset: 1630916580

Referenzen

• Die Schnittstellenunabhängige Dokumentation erfolgt in #253 (closed)
• https://wiki.fit-connect.fitko.dev/de/Konzeption/Observability_Monitoring

Akzeptanzkriterien

1. Der Zustelldienst limitiert die Anzahl neuer Submissions pro Zeitinterval und Onlinedienst (anhand des Subjects aus dem Access Tokens). -> Wert noch festzulegen
2. Der Zustelldienst limitiert die Anzahl der Anfragen pro Antragsvorgang und Zeit (anhand der caseID). -> Wert noch festzulegen
3. Im API-Gateway (?) ist ein Rate-Limiting auf IP-Ebene konfiguriert. -> Wert noch festzulegen
4. Rate-Limit-Infos werden im HTTP-Header konform zu https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers dargestellt.
5. In der API-Spec der Submision API wird auf den Doku-Artikel verwiesen.
6. Das Auslösen von Callbacks unterliegt einem strengen Rate-Limiting (ggf. domain-/IP-basiert?), sodass durch das Anlegen vieler Submissions nicht beliebig viele Callbacks gegen fremde Systeme ausgelöst werden können.