Vereinheitlichung Responses für POST/PUT Submissions

Warum?

(Diese Story ist ein Follow-Up Task aus dem API-Spec Review: #47 (closed))

Aktuell werden für POST /v1/submissions und PUT /v1/submissions/{submissionId} unterschiedliche Responses zurückgesendet. Prinzipiell liegen identische Informationen nach dem POST und PUT vor, sodass die Responses identischer aufgebaut werden könnten. Hierdurch wird das Verständnis der API Spec vereinfacht.

Relevante Links und Bemerkungen

• Submission API: https://docs.fitko.de/fit-connect/docs/apis/submission-api/
• Auch die umgesetzte API Version in ZSD aktualisieren: https://git.fitko.de/fit-connect/zustelldienst/blob/main/src/main/resources/application.yml#L133

Akzeptanzkriterien

1. Bei POST /v1/submissions wird die gleiche Antwort (mit Ausnahmen, s.u.) wie bei PUT /v1/submissions/{submissionId} zurückgegeben.
2. Bei POST /v1/submissions macht nur ein leeres attachments Array Sinn, da dieses Array die bereit hochgeladenen Attachments darstellt.
3. Bei beiden Endpunkten sollen attachments, ~~announcedAttachments ~~ und serviceType zurückgegeben werden. (Anmerkung 17.4: announcedAttachments soll nach Abstimmung gar nicht zurückgegeben werden.)
4. Ausnahme: Das Feld callback soll beim Endpunkt POST /v1/submissions nicht zurückgegeben werden, da es beim PUT Endpunkt schon deprecated ist.
5. Das Release der neuen API-Version ist ein Minor-Change, da hier nur zusätzliche Datenfelder zurückgegeben werden.

Durchführungsplan

• ...
• ...
• ...

Follow-Up

• prüfen ob announcedAttachments grundsätzlich in attachments bei POST /v1/submissions umbenannt wird (Zweck: Vereinheitlichung und Durchgängigkeit)