Methodensignaturen .NET-SDK [M]
Warum?
Als Vorbereitung zur Erstellung des .NET-SDK soll die Funktionalität und Benutzbarkeit des .NET-SDK auf Grundlage eines Grundgerüstes für eine C#-Bibliothek abgestimmt werden. Hierfür soll eine Library erstellt werden, die nur Methodensignaturen und die Doc (aber keine Implementierungen) enthält.
Relevante Links und Bemerkungen
- SDK-Konzept im Wiki
- inoffizielles Python-SDK
- Code-Generierung aus OpenAPI-Spec?
- GGf. Code zwischen Zustelldienst und SDK sharen?
- Gedanken über Versionsmanagement der API
- Für Rückkanal wird voraussichtlich OpenAPI 3.1 benötigt. Ggf. beachten bei Code-Generierung (Tools für OpenAPI 3.1 sind noch nicht so weit: https://github.com/OpenAPITools/openapi-generator/issues/9083)
Akzeptanzkriterien
- Im GitLab findet sich unter https://git.fitko.de/fit-connect/sdk-dotnet ein Grundgerüst des SDKs mit Methodensignaturen.
- Jede Methode ist ausführlich mittels C# Doc dokumentiert.
-
Alle Methoden werfen eine
NotImplementedException
(o.ä.) -
Die folgenden Funktionalitäten sind abgebildet (nicht jede Funktionalität muss zwangsläufig über eine eigene Methode abgebildet werden, ggf. reicht auch ein
// TODO: implement xyz
):- Sender + Subscriber: Abruf von OAuth-Tokens
- Sender: Prüfung von öffentlichen Schlüsseln und Zertifikatsketten + OCSP-Check (vgl. #119 (closed))
- Sender: Verschlüsselung von Fachdaten (JSON, XML) mittels JWE
- Sender: Verschlüsselung von Anhängen (Binärdaten) mittels JWE
- Sender: Korrekte Erzeugung eines Metadatensatzes inkl. Hashwerte
- Subscriber: Entschlüsselung von Fachdaten (JSON oder XML) mittels JWE
- Subscriber: Entschlüsselung von Anhängen (Binärdaten) mittels JWE
- Subscriber: Prüfung der empfangenen Metadaten gegen das zugehörige JSON-Schema
- Subscriber: Prüfung der Hashwerte aus dem Metadatensatz.
- Subscriber: SET-Erstellung inkl. Signaturerzeugung
- Sender + Subscriber: SET-Empfang inkl. Signaturprüfung
-
Sender + Subscriber: Unterstüzung / Abstraktion der API-Nutzung (
fitconnect.sendSubmission(metadata, destinationID, ...)
o.ä.) für die oben genannten Use-Cases - Logging (Logging-Modul muss von außen kommen)
Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)
- Lesen der Wiki-Seite, Klärung von offenen Fragen
- ...
- ...
- ...
- Definition of Done wurde geprüft