Consider adding multiple ways to use this library

[sander1095]

Currently to use this library, you have to perform the following steps:

• Add the HATEOAS action filter to your MVC filters
• Make one of your DTO's derive from HateoasObject or implement IHateoasObject
• Implement the IHateoasProvider<> (or async version) for your DTO.

This is pretty clean, pretty OOP and very testable. But you could also argue it's kind of verbose and "ugly" that my library requires that a user changes their DTO's.

What if we could have some alternative approaches on using this library in your codebase? The user could then choose which version they like best. One immediate downside of this feature would be added complexity to the codebase, and perhaps also for the user. Instead of having 1 implementation they can now choose multiple options. If there are too many options, it might become annoying because different codebases will implement things in different ways.

I could come up with multiple alternatives:

Use attributes on the DTO instead of HATEOAS

Instead of making classes inherit from DTO, Provide some attribute like [HateoasObject] or [HateoasCollection] that people can put on their DTO's. Our library would then look for these and add links to the DTO at runtime.

Tradeoffs

• Less invasion of a user's projects.
• I personally like using nswag to generate API Clients. WIthout attributes, it might be more difficult to make the api client generator add the HATEOAS properties (links) back to the generated DTO's. Perhaps something with OpenApi could be done?
• Reflection is possibly slow! But I think we already use reflection right now, anyway, so how much does it matter?

Use attributes on the Controller Action instead of the DTO

Inspired by [Produces] that you can put on a controller, what if we have something like [Hateoas(href, action, rel)] that you put on a controller's action which indicates that this method returns some hateaoas link? Perhaps the attribute could even have a Policy or Role property that could be used to determine if the link should be added! This way, you do not need to edit your DTO's at all! You might not even need the hateoas providers anymore!

Tradeoffs

• Less invasion of a user's projects.
• I personally like using nswag to generate API Clients. WIthout attributes, it might be more difficult to make the api client generator add the HATEOAS properties (links) back to the generated DTO's. Perhaps something with OpenApi could be done?
• Reflection is possibly slow! But I think we already use reflection right now, anyway, so how much does it matter?
• Less flexible than the provider approach.

Ending

It is important that some discussions take place about these options, and I think the library has to be in use for a while before we really know if this is a good idea.

• Do users think something is wrong with the current approach? Could we instead improve our current approach instead of adding more options?
• Consider all the trade offs (complexity, performance, "fitting in" with ASP.NET Core's code)