I'm facing an issue wrapping some of my APIs calls in different NuGet packages.
All errors returned by the APIs are using the ProblemDetails/ValidationProblemDetails classes thanks to the Hellang.Middleware.ProblemDetails package I discovered recently.
Now the issue is: When adding the API wrapper NuGet packages to my client applications, I prefer not leaving the deserialization task of the response.Content to them (call being successful or not).
This would produce mainly 3 response types:
Success=>Expectedregular object, that can change for each method exposed by the APIBadRequest=>ValidationProblemDetails- Any other error =>
ProblemDetails
My main issue handling the deserialization within the wrapper is that ProblemDetails/ValidationProblemDetails classes are "deeply" rooted in the Microsoft.AspNet.Mvc.Core namespace and thus in the corresponding NuGet package (no abstraction that I know of).
It seems overkill to include such a package as a direct dependency to a simple API wrapper in my opinion (but I may be wrong thinking this way, feel free to correct me).
Unfortunately, according to https://github.com/dotnet/aspnetcore/issues/7679, the situation is not bound to change anytime soon.
I've thought of making a NuGet package of my own including those classes and having it as a dependency spread across all my wrapper but I'm not very fond of this solution.
If anyone has better ideas or solutions to handle this (returning a proper ProblemDetails object, directly from the API wrapper), they're very welcome.