Determine usability of WebAPI

[stijnmoreels]

During the slimmed-down exercise, it came to our attention that lots of Arcus functionality should be reviewed in terms of usability, in favor of using new built-in Microsoft supported functionality. This discussion item showcases what current functionality should either be removed or changed.

• ❌ Remove Arcus.WebApi.Hosting.AzureFunctions package, as this package is only used for Azure Functions - which we stop supporting directly in other Arcus repo's. The only functionality here is that it can restrict isolated HTTP functions to only use JSON request/response, which by itself is a rather project-specific setup that would possibly require customization of error messages and/or a range of 'accepted' content types. The added-value of this package is therefore rather minimal and only usable in very specific circumstances.
• ❌ Remove Arcus.WebApi.Logging.AzureFunctions package, as this package only has two middleware components (exception handling + request tracking). The exception handling is a very small component, that needs possibly be configured specifically for each project, which makes it a rather un-Arcus thing. The request tracking middleware component builds on the Arcus.Observability Serilog setup, which is also being reviewed and possibly removed. Also: Azure Functions is being stopped supporting built-in for Arcus.
• ❌ Remove Arcus.WebApi.Logging package, as this mostely provides correlation formats that are either deprecated (Hierarchical) or built-in supported by OpenTelemetry (W3C) in ASP.NET Core applications (https://learn.microsoft.com/en-us/dotnet/core/diagnostics/observability-with-otel)
• ❌ Remove the direct link with Arcus.Security in the Arcus.WebApi.Security, so that both packages can continue being developed separately.
  • The functionality of this package should also be reviewed. We currently have SharedAccessKey, Certificate and JWT as authentication systems, which some of them might already be suppored by Microsoft, now.
  • This has also impact on the .OpenApi.Extensions package, that provides OpenAPI documentation for the authentiation filters.
• ❌ Remove the Arcus.WebApi.Hosting package, as it only has a single extension there to only allow JSON formatting in API applications - which is too project specific.

[stijnmoreels]

Wondering if this entire repository should be archived, even.

Edit: now I'm even more sure that there is not a real added value to this repo, as OpenTelemetry already has a request tracking functionality available for ASP.NET Core.

[fgheysels]

I was taking a look around and noticed that there exists middleware which logs requests / response content in the .NET SDK: UseHttpLogging.

[fgheysels]

Some input:

• I agree with removing the Azure Functions specific projects.
• I agree with removing the Arcus.WebApi.Hosting package, as I believe the functionality that is present there (enforcing json formatting), can also be achieved via the ProducesAttribute and ConsumesAttribute.

Logging projects

• Arcus.WebApi.Logging contains some middleware components that are -imho- still interesting:
  • ExceptionHandlingMiddleware: used to catch unhandled exceptions and return an appropriate HttpStatus code without revealing exception details. I believe this one is still relevant.
  • RequestTrackingMiddleware: we can make it obsolete in the version that will target .NET 10 and define that people should look at the UseHttpLogging method that exists in a .NET SDK ? (Or create a release of Arcus.WebApi prior to the .NET 10 release where we make declare this as Obsolete already ?)
    The UseHttpLogging allows to redact sensitive data and exclude request-tracking of certain paths, but not in the same way as Arcus does.
  • VersionTrackingMiddleware: idk if this is very relevant ? Do we want to include the version in every request - trace ? There is even a warning notice in the documentation that says that this should not be used for public endpoints. (I don't even know if you can configure this middleware on certain endpoints only). I'd say we should deprecate this middleware.
  • CorrelationMiddleware: I wonder if this one still brings additional value to the table. I removed it from one of my projects, and I don't notice any difference in correlation tracking with or without this middleware ?
  • I think we can remove the link to Arcus.Observability, if we only keep the ExceptionHandlingMiddleware class ?
  • Should we merge Arcus.WebApi.Logging & Arcus.WebApi.Logging.Core into one project / package ?

Security project

• Certificate authentication: ASP.NET has some built-in functionality for this as well (see here). However, Arcus allows you to configure this on an operation level, whereas this is not possible via the built-in ASP.NET functionality. This is because ASP.NET handles the certificate authentication at the start of the HTTPS conversation. Is it valid to keep this authentication method in Arcus for this reason ? Personally, I believe the way certificate authentication is configured / setup via Arcus is also a bit easier / more straightforward.

• Shared Access Key authentication: I cannot immediately find anything build in for this in ASP.NET. I do find tutorials on how to implement this in ASP.NET on how to do this yourself, so I believe no built-in functionality exists in ASP.NET.

• JwtBearer: the extension method that we have, seems to be just a wrapper around the ASP.NET AddJwtBearer method. It also adds the Action<JwtBearerOptions> delegate to the DI container, but IDK why ....

• Authorization: this namespace contains the JwtTokenAuthorizationFilter and JwtTokenReader which can be used for backdoor authentication. I think this is still useful.

OpenApi Extensions

I believe these are still very useful, but we might have to review if they're still working with the latest versions of Swashbuckle.

My 2 cents:

• Remove Azure Functions specific projects
• Remove Arcus.WebApi.Hosting
• merge Arcus.WebApi.Logging and Arcus.WebApî.Logging.Core into one project (Arcus.WebApi.Logging). Keep the ExceptionHandlingMiddleware. Deprecate the VersionTrackingMIddleware, CorrelationMiddleware and RequestTrackingMiddleware.
• Keep the Certificate Authentication and Shared Access Key Authentication functionality. The custom extension method for JwtBearer authentication is up to discussion.
• Keep the Authorization namespace.
• Keep the OpenApi.Extensions project.

Any thoughts or input @stijnmoreels , @gverstraete ?
Also interested in the opinions of @LodewijkSioen, @meersschautarnaud , @rodrigost as they're using Arcus.WebApi as well in some of their projects.
And maybe @pim-simons also knows some ppl who are using Arcus.WebApi.

[LodewijkSioen]

My input:

Main takeaway: if built-in alterenatives exists (or other projects with similar functionality), then we should not put effort into maintaining a solution ourselves.

Logging Projects

• ExceptionHandlingMiddleware: If I understand the code correctly, this will just return the statuscode to the client and no further info. The actual error only lives in logging (AppInsights or whatever).
  Is the currennt best practice not to use ProblemDetails for this? If you really don't want any details in the response, you can use the IProblemDetailsWriter to customise the output.
• RequestTrackingMiddleware: Seems dangerous to keep if this can leak PII data. Also: UseHttpLogging exists.
• VersionTrackingMiddleware seems to be very project specific?
• CorrelationMiddleware: I also thing that this one is better handled by the framework nowadays.

Security Project

I should spend some time to look at these projects. I might be wrong, but a lot of this stuff seems to be built-in? I recently did Certificate Auth using raw dotnet.

OpenApi

These seem to be very project specific? I feel like this is more templated code that can be copied around from project to project and then tweaked for the specifics.

[stijnmoreels]

Yes, like mentioned in the original start of this discussion, I believe that the current stuff in source control is either (now) already available built-in, too project specific, or something we don't support anymore (like Azure Functions).