Explorer les filtres ASP .NET Core Web API

Aujourd’hui on va s’intéresser aux filtres en ASP .NET Core.

Je me suis aperçu qu’il y avait une confusion entre les filtres et les middlewares.

En effet, les deux se ressemblent sur le papier mais n’utilisent pas les mêmes choses.

Voici la pipeline d’exécution d’un middleware :

Et celle d’un filtre :

On voit tout de suite que les filtres passent après les middleware dans la pipeline et de plus, ils n’utilisent pas les mêmes données.

Les filtres utilisent le context MVC et les middleware utilisent plutôt le contexte de la requête comme les headers etc.

Pour faire simple, les filtres sont utilisés pour intercepter une requête et/ou une réponse durant le traitement de la requête.

Ils peuvent servir à plein de choses comme l’authentification, les logs, le caching etc.

Dans le détail, les filtres sont un ensemble de classes ASP .NET qui sont utilisées pour intercepter une requête et/ou une réponse et ces filtres peuvent être appliqués globalement, au niveau du controller ou de l’action.

Il existe 6 types de filtres qui s’exécutent à différents endroits de la pipeline d’exécution d’une requête :

• Authorization filters :
  • s’exécute en premier
  • Détermine si l’utilisateur est autorisé
  • Court-circuite la pipeline si ce n’est pas le cas
• Filtres de ressources :
  • Exécuté après l’autorisation.
  • OnResourceExecuting exécute le code avant le reste du pipeline de filtre. Par exemple, OnResourceExecuting exécute le code avant le model binding
  • OnResourceExecuted exécute le code une fois le reste du pipeline terminé.
• Filtres d’action :
  • Exécuté immédiatement avant et après l’appel d’une méthode d’action.
  • Peut modifier les arguments passés dans une action.
  • Peut modifier le résultat retourné par l’action.
  • Ne sont pas pris en charge dans Razor Pages.
• Filtres de Endpoint :
  • Exécuté immédiatement avant et après l’appel d’une méthode d’action.
  • Peut modifier les arguments passés dans une action.
  • Peut modifier le résultat retourné par l’action.
  • Ne sont pas pris en charge dans Razor Pages.
  • Peut être appelé sur les points de terminaison basés sur des actions et sur des gestionnaires de routage.
• Les filtres d’exception appliquent des stratégies globales aux exceptions non gérées qui se produisent avant que le corps de la réponse ait été écrit.
• Filtres de résultats :
  • Exécuter immédiatement avant et après l’exécution des résultats de l’action.
  • Exécuter uniquement lorsque la méthode d’action s’exécute correctement.
  • Sont utiles pour la logique qui doit entourer l’exécution de la vue ou du formateur.

Par conséquent chaque filtre va avoir sa propre interface et donc sa propre implémentation.

Action Filter

Par exemple si nous prenons le filtre d’action, et créons une classe ActionFilter qui héritera de IActionFilter , ASP .NET va vous “forcer” à implémenter deux méthodes :

• OnActionExecuting pour l’éxécution de l’action
• OnActionExecuted une fois l’action exécutée

Comme vous pouvez le voir, vous avez accès au ActionExcutingContext et celui-ci vous permet de manipuler les données en entrée et en sortie comme pour vérifier que le modèle en entrée est valide (ModelState.IsValid ) par exemple :

Je vais passer en revue rapidement les différents types de filtres.

AuthorizationFilter :

Ici j’ai ajouté un héritage à “Attribute” qui nous permettra d’utiliser le filter sur une action comme ceci :

ResourceFilter

EndpointFilter

Exception Filters

Result Filter

Chaque type de filtrer peut être implémenté de manière synchro ou asynchrone bien sur comme par exemple le result filter :

Chaque type de filtre a son interface dédiée pour faire du synchrone ou de l’asynchrone.

Les filtres ont bien sur des constructeurs qui vous permettront de faire de l’injection de dépendances.

Par exemple si vous avez besoin d’avoir une accès à la base de données, vous pouvez injecter les services nécessaires comme dans l’exemple de l’Exception Filter.

Si je devais résumer l’utilité des filtres :

• Réutilisabilité : les filtres peuvent être appliqués à plusieurs niveaux (global, contrôleur ou action), ce qui les rend réutilisables dans l’ensemble de l’application.
• Séparation des responsabilités chère à nos amis fan des principes SOLID : les filtres permettent aux développeurs de séparer les responsabilités des classes telles que l’authentification, l’autorisation, la journalisation, la mise en cache et la gestion des exceptions de la logique métier principale de l’application.
• Facile à tester : les filtres peuvent être testés indépendamment, ce qui facilite l’identification et la résolution de tout problème lié à ceux-ci.
• Performances améliorées : les filtres peuvent être utilisés pour effectuer des tâches telles que la mise en cache, ce qui peut améliorer les performances de l’application.

Les API REST sont stateless, ce qui signifie que chaque requête est indépendante de la précédente. Les filtres peuvent être utilisés pour gérer divers aspects d’une API REST tels que l’authentification, l’autorisation, la validation du modèle, la gestion des erreurs et la journalisation. En utilisant des filtres, vous pouvez vous assurer que l’API est sécurisée et fiable.

Sur ces bonnes paroles, je vous invite chaudement à tester les filtres et les implémenter car ils sont une feature importante d’ASP .NET Core Web API.

Have fun coding ! 😎