Routing API: Anpassung Rückkanaloptionen

Warum?

In der Routing API gibt es aktuell bereits ein replyChannels-Objekt. Allerdings noch am "alten Ort" und nicht innerhalb des services-Objekts.

Ziel dieses Issues ist es, die Routing API der Self-Service API an dieser Stelle anzugleichen.

Ausstehende Architekturentscheidung

Die Infos aus der Routing API (destinationParameters) stehen aktuell auch über die Submission API und die Self-Service API zur Verfügung. Es wäre zu überlegen, ob wir die Informationen perspektivisch nur noch über die Submission API / Self-Service API bereitstellen, sodass die Routing API nur noch die Destination-ID zurückgibt.

Zu beachten dabei: Die Routing API gibt ab Version 1.1.0 auch weitere Parameter im Kontext der sog. EfA-Parametrisierung aus.

Relevante Links und Bemerkungen

Akzeptanzkriterien

1. ...
2. ...
3. ...

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

• ...
• ...
• ...
• Definition of Done wurde geprüft

assigned to @Marco_Holz

assigned to @Marco_Holz

Nicht mehr vor Produktivsetzung Routing API v1.

changed title from Vorschlag für Merge Request f. Routing API to Vorschlag für Merge Request f. Routing API (Anpassung f. Rückkanaloptionen)

changed the description

added team::RTD label

changed title from Vorschlag für Merge Request f. Routing API (Anpassung f. Rückkanaloptionen) to Routing API: Anpassung Rückkanaloptionen

changed the description

added 1 deleted label

changed milestone to %Backlog

marked this issue as related to #516

marked this issue as related to #507 (closed)

added Epic::Bidirectional-Communication label

added 1 deleted label and removed 1 deleted label

added type::Story label

@Marco_Holz kannst du das bitte vervollständigen, oder löschen?

Habe eine Story-Beschreibung ergänzt. Über dieses Issue sollten wir nochmal gemeinsam reden. // cc @Jonas_Groeger

changed the description

added 1 deleted label and removed 1 deleted label

Es wäre zu überlegen, ob wir die Informationen [destinationParameters] perspektivisch nur noch über die Submission API / Self-Service API bereitstellen, sodass die Routing API nur noch die Destination-ID zurückgibt.

Vorteile

• Infos nur an einer Quelle der Wahrheit ("single source of truth"). Die Möglichkeit des Auseinanderlaufens gibt es daher nicht.
• Komplexitätsreduktion (durch Löschen von Code) im Routingdienst.
• Die Info ist teilweise schon in der destinationSignature vorhanden. Ein entfernen der destinationParameters bedeutet auch hier weniger Verwirrung, auch wenn die URLs fast gleich sind (Host vs. Endpunkt).
  • destinationSignature hat submissionHost: submission-api-dev.fit-connect.fitko.dev
  • destinationParameters hat submissionUrl: https://submission-api.fit-connect.example.org/v1

Nachteile

• Extra Call notwendig um alle Informationen abzurufen.
• Minimalst mehr Last durch obigen extra Call
• Infos nicht verfügbar wenn Zustelldienst / SSP-API down.

Ich sehe hier v.a. die Komplexitätsreduktion und "single source of truth" als Schlüsselargument und wäre für diese Variante.

Ein Löschen der Felder in der Routing-API wäre natürlich ein Breaking Change den man begleiten muss (Konsumenten benachrichtigen, Doku, Übergangsfrist)

added Epic::Routing-API-destinationParameters-removal label and removed Epic::Bidirectional-Communication label

added Routing label

unassigned @Marco_Holz