Les Web APIs en .NET Core
0 j'aime79 vues
Le document présente plusieurs types d'API Web en .NET Core, y compris REST, OData, GraphQL et gRPC, en détaillant leurs avantages et inconvénients. Chaque technologie est décrite avec ses principes de fonctionnement, ses outils et ses spécificités en termes de performance et d'implémentation. Le document souligne également des problématiques comme le versioning et la gestion des types de données dans les échanges entre client et serveur.
Les Web APIs en .NET Core
- 1. Les Web APIs en .NET Core François Camus Jérôme Péronne
- 3. REST ● REpresentational State Transfer ● Introduit par Roy Fielding en 2000 ● Tout est une ressource identifié par un Uniform Resource Identifier (URI) ● Utilise le protocole HTTP ○ Méthode HTTP pour différencier les contextes d’accès à une ressource ○ Représentation des ressources en JSON, XML... ● Versioning ● Outils ○ Swagger (Swashbuckle ou NSwag) ○ Génération du code de l’API Client (NSwag)
- 4. Démo
- 5. Avantages ● Stateless ● Séparation entre client et serveur ○ Facile d’ajouter un nouveau type de client ● Simple à mettre en place ● Facilement scalable ● Support d’un grand nombre de types de média ● Supporté par tous les navigateurs ● Caching
- 6. Inconvénients ● Chatty ○ Beaucoup d’information transite ● Over fetching et under fetching ○ Structure rigide des données ● Typage faible entre client et serveur ● Pas facile à implémenter correctement ○ REST vs HTTP ○ Tout n’est pas resources ○ Création de endpoints spécifiques avec des GET et POST ● Versioning d’API peut devenir compliqué ○ URL ○ Header
- 7. OData ● Open Data Protocol ○ Créé par Microsoft en 2007 ○ Version 4 standardisé OASIS en 2014 ○ Basé sur HTTP, AtomPub et JSON ○ Mature en ASP.NET mais pas encore en ASP.NET Core (quelques bugs) ● Permet de requêter et manipuler des données de façon uniforme ○ Opérations CRUD ● Metadata ○ Description du modèle de données ○ Entity Data Model - Entity Framework ● Versioning ● Outils ○ Swagger via Swashbuckle ○ Génération du code possible de l’API client
- 8. Démo
- 9. Avantages ● Standard très mature (12 ans) ● Requêtage puissant ○ Ordonnancement ○ Paging, sorting et filtering ○ Contrôle du volume de données ○ Presque SQL via URL ● Facile à mettre en place ● Moins bavard que REST
- 10. Inconvénients ● Manque de contrôle sur les requêtes effectuées par le client ○ $expand, $filter… définis par le client ○ Difficile d’anticiper des problèmes de performance spécifiques à un client ○ Cas d’utilisation pas défini d’avance ○ Utilisation en interne (Applications CRUD) ● Couplage fort avec les entités définies dans Entity Framework ○ Pas trop le choix de retourner les entités au client ● Ne semble pas très populaire
- 11. GraphQL ● Créé par Facebook ● Rendu open source en 2015 ● Surcouche d’une API REST permettant de requêter des données typées ● Spécification qui décrit les possibilités et les besoins en terme de données entre un client et un serveur ● Outils ○ GraphiQL ○ Apollo
- 12. Démo
- 13. Avantages ● Peut se mettre en surcouche sur un système existant ● Moins bavard que REST ● Communauté grandissante ● Agrégation/orchestration des données de plusieurs sources différentes ● Tous les cas d’utilisation/requêtage doivent être défini ● Le client demande les données dont il a besoin ni plus ni moins ● Le client dicte la forme de la réponse qu’il souhaite ● Indépendance des développeurs front et back ● Possibilité de souscrire à un flux de données (Observable) ● Versioning ○ Les propriétés actuelles peuvent être déprécié (client reçoit un warning) ○ Ajout de nouvelles propriétés sans impacter les clients actuelles ● Outils ○ GraphiQL (système d’introspection)
- 14. Inconvénients ● Complexité ○ Pas mal de code pour la plomberie côté backend => Schéma ○ Ne vaut peut-être pas le coût si le format des données de change jamais ● Caching ○ Pas comme REST basé sur les URLs => Resource level caching ○ Les requêtes peuvent être différentes ■ Field level caching ■ DataLoader en GraphQL .NET ● Fait pour retourner du JSON ● Pas de paging, filtering et sorting de base ● Fait pour gérer des données typées et pas des données dynamiques
- 15. gRPC ● gRPC a été développé initialement par Google puis rendu open source. ● Permet de réaliser des clients et serveurs rpc via HTTP/2 et donc de profiter de ses nouveautés. ● Les données sont sérialisées et désérialisées grâce à Protocol Buffers. ○ Protocol Buffers = format de sérialisation avec un langage de description d'interface (IDL) développé par Google ● Le framework gRPC permet aussi d’avoir un client et un serveur dans différents langages.
- 16. Démo
- 17. Avantages ● Performance grâce à HTTP 2 ○ Tramage binaire et compression ○ Multiplexage de plusieurs appels via une connexion TCP unique. ○ Streaming bidirectionnel ● Langage de description : Protobuf 3 ○ Compact, strict, rapide ○ Rétrocompatibilité des messages ○ Génération automatique de code client ■ Android Java, C#,C,Dart,Go,Java,Node,PHP,Python,Ruby ● Pleinement supporté sous .NET Core 3
- 18. Inconvénients ● Trames binaires incompréhensibles par l'humain ● Prise en charge de navigateur limitée ○ gRPC-Web fournit une prise en charge limitée de gRPC dans le navigateur. ○ gRPC-Web se compose de deux parties: un client JavaScript qui prend en charge tous les navigateurs modernes et un proxy sur le serveur. Le client gRPC-Web appelle le proxy et celui-ci transfère les requêtes gRPC au serveur gRPC. ○ https://grpc.io/blog/state-of-grpc-web/
- 19. Code source https://github.com/FrancoisCamus/WebApisInNetCore - François Camus Twitter: @francois_camus GitHub: FrancoisCamus LinkedIn: francoiscamuspro - Jérôme Péronne GitHub: winswolf LinkedIn: jérôme-peronne-aa762088
- 20. Thank you!