Présentation donnée lors du meetup MUG.Net à Nantes le 27/06/2019. Détails: "Dans ce meetup nous parlerons des différentes façons d'implémenter une Web API en .NET Core. Autour d'un exemple d'API REST, nous discuterons des avantages et inconvénients d'une surcouche GraphQL ou OData. Nous ferons aussi une introduction au prochain framework gRPC en le comparant à REST." Lien Meetup: https://www.meetup.com/Meetup-Mug-Net-Nantes/events/261924045/

1. Les Web APIs en
.NET Core
François Camus
Jérôme Péronne

2. Modèle de données

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!