Create and publish Dialogporten Serviceowner client library nuget

[elsand]

Introduction

As a part of the integration in Altinn 3 storage and apps, Dialogporten should offer a Refit-based client SDK based on https://github.com/altinn/altinn-apiclient-maskinporten

Description

In order to make it easier to integrate with Dialogporten Serviceowner API, we offer a .NET based SDK.

The library should also offer a way to validate dialog tokens.

Implementation

The implementation should be based on Refit, but supply a higher-level API for ease-of-use. Consider using Refitter for generating the Refit interfaces, which hopefully will lighten the maintenance burden. This could be used against swagger-verified.json.

The implementation should focus on HttpClientFactory and DI usage (ie. wrap AddMaskinportenClient).

The dialog token validation should not depend on/or integrate with Microsoft.IdentityModel, but offer a more low-level API.

A package that implements something that can be readily used with Microsoft.IdentityModel and the ASP.NET Core authentication pipeline is out of scope for this package, and should be implemented separately (depending on this package), as the current MS implementation in .NET lacks EdDSA support and building a custom one is non-trivial as some central mechanisms lack async support.

Tests

A integration test similar to FailIfSwaggerSnapshotDoesNotMatch should be implemented, that runs Refitter against docs/scheme/V1/swagger.verified.json and compares the generated file against the one that is used in the SDK. As with the Swagger check, any diff should cause a failure. Updating the one used in the SDK will force the SDK implementation to adhere to any changes made to the API.

There should also be a test project for creating integration tests, which refers to the SDK project. TODO! Define how these should be made, and what should be mocked.

Tasks

Preview Give feedback

1. Determine SDK API
2. Implement the client
3. Create a README explaining basic usage
4. Set up build and nuget publish pipeline
5. Create integration tests

Threat modelling

Preview Give feedback

1. Needs to manage secure API access to nuget.org (Altinn org)

[MagnusSandgren]

"Konklusjon" fra refinement 23.10.24:
Ettersom SDK oppgaven blir den første som faktisk konsumerer open api specen vår (etter swagger) ser vi noen svakheter med måten vi har løst navne-kollisjoner på.

Differansen vi har brukt mellom enduser og serviceowner, med å postfixe "SO", til både operationId og typer tar ikke hensyn til fremtidig versjonering. Ei tar vi heller hensyn til sub-typer innenfor flere vertikaler, som vi nå har løst med å prefixe alle typene med feature navnet i noen kontekster (eks GetDialogDialogTransmissionContentDto vs GetDialogTransmissionContentDto).

Dette var trolig gjort i sin tid for å prettify'e standardnavnene som prefixer hele namespacet på navnet som default, eks GetDialogDto blir Digdir.Domain.Dialogporten.Application.Features.V1.EndUser.Dialogs.Queries.Get.GetDialogDto (uten punktum).

Her er det X mulige veier til mål:

1. Ta bort Digdir.Domain.Dialogporten.Application.Features. prefix fra alle typer og operasjonsnavn i swagger. Her vil vi prettify'e navnene noe uten å være engstelig for å få kollisjon mellom versjoner, enduser/serviceowner, eller vertikaler - gitt at vi holder oss til mappestrukturen slik den er i dag.
2. Undersøke namespacing i open api spec og bruke det for å potensiellt få det beste av begge verdener - altså ingen kollisjoner og fine navn.

@elsand ☝️ Du var savner på refinement 😅 Har du noen innspill?

[elsand]

@Fargekritt @MagnusSandgren La til et punkt i teksten vedrørende testing. Det er ikke klart for meg hvordan en integrasjonstest av SDK-prosjektet bør fungere, siden det da er tenkt å skulle gå mot et kjørende API av Dialogporten. Har dere noen innspill her?