Erstellen der Destination API Spezifikation
User Story
Als SSP-Team möchte ich die Daten von Destinations und Clients ausschließlich über den ZSD verwalten.
Why
Links, Notes, Remarks
- Scope mit langem Präfix:
https://schema.fitko.de/fit-connect/oauth/scopes/…
- Die Destination API wird (zukünftig) vom Zustelldienst implementiert (siehe Story #1804 (closed)).
- In automatisierten Blackbox Tests (Lasttests, …) können die neuen API-Endpunkte anschließend verwendet werden statt statisch Destinations zu konfigurieren.
- Unverifizierte Annahme zur Trennung der 2 APIs: Die Destination API wird sich schneller / langsamer entwickeln als die Submission API.
- Diff der beiden APIs
Acceptance criteria
-
Es gibt eine neue in der Doku verlinkte API: "Destination API". -
Die Destination API hat die Endpunkte der Self-Service API mit einigen Änderungen bzgl. der Ownership / Namen. -
Die Endpunkte aus dem Abschnitt Internal
aus der Submission API sind in der Destination API vorhanden. -
Die Endpunkte aus der bisherigen direkten Backend<->SSP-DB Kommunikation sind in der Destination API vorhanden -
Die Versionierung der Destination API ist separat von der der Submission API. Unverifizierte Annahme zur Trennung der 2 APIs: Die Destination API wird sich schneller / langsamer entwickeln als die Submission API -
Die Scopes zur Verwaltung von Destinations nutzen den langen Präfix -
Die Destination API ist mit Team SSP abgestimmt.
Implementation plan (to be completed by the developer)
-
... -
... -
... -
Definition of Done was checked.
Edited by Wojciech Gdaniec