Durchgängiges Beispiel für Getting Started inkl. Bereitstellung eines Testdatensatzes
Warum?
In vielen Beispielen sind unterschiedliche Anträge, URLs etc. beschrieben. Das verwirrt die Leser.
Um Getting Started besser für Entwickler Hands's on nutzbar zu machen, soll ein durchgängiger Beispielspieldatensatz genutzt werden, der für alle API-Aufrufe und technische Aufgaben (Schemavalidierung) genutzt werden kann.
Referenzen
Akzeptanzkriterien
-
Die einheitlichen Beispieldaten sind im Wiki dokumentiert und mit einem PO abgestimmt. -
Metadatenschemas, API-Aufrufe nutzen einheitlich den konstruierten Beispieldatensatz -
Alle Aufrufe bzw. Erklärungen verweisen auf einheitliche URLs, dem Domänen-Modell entsprechend -
Die Aufrufe und Nutzung des Beispieldatensatzes kann einfach verfolgt werden (z.B. via curl und ajv (Validierung d. Fachdaten & Metadaten)) -
Der Beispieldatensatz enthält folgende Bestandteile und steht öffentlich zur Verfügung: -
Metadatensatz (vgl. originale Beispiele): - Ein identificationReport
- Einen Bezahlungsnachweis (PaymentInfo) mit Minimalbefüllung
- Eine Mailadresse als Replychannel, der an ein erreichbares Postfach verweist (ggf. mit automatischer Glückwunsch Nachricht)
- 1-2 PDF Anlagen
-
Ein Zertifikat zur Prüfung des identificationReport -
Einen Fachdatensatz (gemäß den Angaben des Metadatensatzes) - Fachdatensatz soll ein JSON Schema besitzen
- Er soll relativ einfach sein (z. B. Hundesteuer)
- XML oder speziell XÖV sollte nicht genutzt werden, da kompliziert und extra Tooling notwendig
-
Das Schema des Fachdatensatzes (gemäß den Angaben des Metadatensatzes) -
1-2 PDF Anlagen (gemäß den Angaben des Metadatensatzes) -
Ein SET für die Accepted Meldung -
Eine Musterkonfiguration für eine Destination (Kann im SSP per Copy&Paste eingefügt werden) -
Zwei Musterkonfigurationen, für einen Sender und einen Subscriber-Client -
Je ein JWK für Verschlüsselung und Signatur
-
Edited by Marco Holz