Open sander1095 opened 2 years ago
Perhaps some more discussions need to take place before this is implemented.
For example, with our current solution we ONLY run munisio's code when it's an MVC related action. That is why we also have easy access to the DTO and hateoas object; it is a part of MVC.
If we were to use the middleware solution, we might no longer have easy access to the concrete type that is being returned, and we would potentially run our library for different types of requests that do not need HATEOAS, like static files? In this case we might optimize it with an if
statement to skip our hateoas code, but how do we determine this?
In any case, I think choosing either MVC or middleware is a good solution; I do not see a reason to implement both so the user can choose, that's a bit overkill for now.
Use this for inspiration: https://github.com/khalidabuhakmeh/GroupsAndFilters ?
Currently, we hook into MVC's filter system to run our HATEOAS code -> Take a look at
HateoasActionFilter.cs
This works, but perhaps improvements COULD be made. I am not sure yet, though!The goal of this issue is to investigate if we could use ASP.NET Core's middleware system instead. If so, we could make our code less dependent on the MVC system and thus more usable in other scenario's.
For example, something like the following (in .NET 5.0)