Skip to content

API-Specs schreiben für Attachment-Limits

Hintergrund

Im Rahmen von #2155 sollen Limits für Attachment-Uploads durch ein komplexes Verfahren bestimmt werden. Dazu müssen in der Destination-API, der Submission-API und der internen Clients-API Endpunkte hinzugefügt und angepasst werden.

Grundsätzlich geht es um diese Limitierungen, die wir in ihrer Gesamtheit als Limit-Tupel bezeichnen:

  • max-number: Maximale Anzahl an Attachments pro Submission der Reply
  • max-size-individual: Maximale Dateigröße eines einzelnen Attachments
  • max-size-aggregate: Maximale kumulierte Dateigröße aller Attachments einer Submission oder eines Replies.

Dabei gilt:

  • Das Limit-Tupel wird bei SENDER-Clients ("Onlinediensten") separat als "send-submission-limit" und als "receive-reply-limit" gesetzt.
  • Das Limit-Tupel wird an einer Destination als "receive-submission-limit" gesetzt.
  • Das Limit-Tupel wird an SUBSCRIBER-Clients ("Fachverfahren") als "send-reply-limit" gesetzt.
  • Eine Erhöhung dieser Limit-Tupel soll vom Anbinder nur beantragbar sein. Der beantragte Wert soll für den Beantrager selbst zwar immer abrufbar sein, aber er soll erst gelten, wenn dieser genehmigt wurde (Endpunkte zum Genehmigen sind NICHT Teil dieser Story).
  • Ein SENDER-Client muss abrufen können, welche Limits für ihn beim Senden an eine Destination gelten.
  • Ein SUBSCRIBER-Client muss abrufen können, welche Limits für ihn beim Senden eines Replies auf einen Case gelten.
  • Diese Limit-Abrufe sollen einen Überblick geben über das Zustandekommen des Limits. Es soll also ersichtlich sein, dass ein Minimum aus Sende-Richtung, Empfangs-Richtung und einem globalen Plattformlimit gebildet wurde.

image

Akzeptanzkriterien

  1. Interne Clients-API: GET /internal/clients/id/limits Gibt für SUBSCRIBER-Clients das aktuell geltende "send-reply-limit" an, das aktuell beantragte Limit-Tupel, das Platform-Limit-Tupel, das Datum der letzten Beantragung, das Ergebnis des letzten Bescheids (akzeptiert oder zurückgewiesen), das Datum des letzten Bescheids und eine Begründung des Bescheids.
  2. Interne Clients-API: GET /internal/clients/id/limits Gibt für SENDER-Clients identische Informationen wie unter (1) an, allerdings doppelt: Als "send-submission-limit" und als "receive-reply-limit".
  3. Interne Clients-API: GET /internal/clients/id/limits gibt in jedem Fall das aktuell konfigurierte Platform-Limit aus, um das SSP dabei zu unterstützen, eine Obergrenze beim Beantragen durchzusetzen.
  4. Interne Clients-API: PUT /internal/clients/id/limits Erlaubt SUBSCRIBER-Clients das Beantragen eines neuen Limit-Tupels als "send-reply-limit".
  5. Interne Clients-API: PUT /internal/clients/id/limits Erlaubt SENDER-Clients das Beantragen eines neuen Limit-Tupels als "send-submission-limit" und als "receive-reply-limit".
  6. Destinations-API: GET /destination-api/v1/destinations/id/limits Gibt das aktuell geltende "receive-submission-limit" an, das aktuell beantragte Limit-Tupel, das Platform-Limit-Tupel, das Datum der letzten Beantragung, das Ergebnis des letzten Bescheids (akzeptiert oder zurückgewiesen), das Datum des letzten Bescheids und eine Begründung des Bescheids.
  7. Destinations-API: PUT /destination-api/v1/destinations/id/limits Erlaubt das Beantragen eines neuen Limit-Tupels als "receive-submission-limit".
  8. Submission-API: GET /submission-api/v1/destinations/id/limits: (Nur abrufbar mit SENDER-Client.) Es wird das aktuell geltende "send-submission-limit" des abrufenden Clients, das "receive-submission-limit" und das "platform-limit" angegeben, sowie das Minimum aus den 3 Tupeln.
  9. Submission-API: GET /submission-api/v1/cases/id/limits: Gibt das aktuelle "submission-limit" und das aktuelle "reply-limit" an. Ersteres besteht aus "send-submission-limit", "receive-submission-limit", "platform-limit", sowie dem Minimum aus den 3 Tupeln. Letzteres besteht aus "send-reply-limit", "receive-reply-limit", "platform-limit", sowie dem Minimum aus den 3 Tupeln.
Edited by Fabian Sudau