Routingdienst 2.0

User Story

Als Betreiber des Routingdienstes möchte ich die beim Endpunkt get /routes abgekündigten Felder (Routingergebnisse) entfernen. Dafür ist eine neue Major-Version erfoderlich. Um den Nutzern für die Umstellung eine Übergangszeit zu bieten, muss die Version 2.0 parallel mit der 1.2 angeboten werden.

Warum

Die Werte der betroffenen Felder werden aus dem DVDV-Microservice bezogen, sie stammen jedoch aus dem Zustelldienst. Da diese Informationen direkt, ohne den Umweg über RTD und DVDV-Microservice, bei Zustelldienst bezogen werden können, sind sie überflüssig. Durch die Entfernung der abgekündigten Felder wird der DVDV-Microservice nicht mehr benötigt und kann eingestellt werden.

Links, Hinweise, Bemerkungen

Der Routingdienst sollte beide Versionen implementieren und für beide Versionen Endpunkte anbieten. Die sollte v1 per Feature-Flag aktivert und deaktiviert werden können, um den Umstieg flexibel zu gestalten.

Akzeptanzkriterien

  1. Der RTD bietet neben den bisherigen Endpunkten (v1) auch Endpunkte für eine Version 2.0 der Routingdienst API an, die die abgekündigen Felder nicht mehr enthält.
  2. Für die Version 2.0 greift der Routingdienst nicht mehr auf den DVDV-Microservice zu.
  3. Die Version 1.2 kann für eine Übergangszeit parallel genutzt und über eine Feature-Flag aktiviert und deaktivert werden.
  4. Die Existenz einer Destination wird nicht mehr über den DVDV-Microservice, sondern durch Abruf des Endpunktes "get /v1/destinations/{destinationId}" der Submission API geprüft. Nur Destinations mit "status": "active" gelten als existent.

Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)

Edited by Andreas Aschauer