다음을 통해 공유

WCF Data Services, Web API, Odata V3 V4, webHttpBinding, HttpClient, SOAP, REST ??

  • 아티클

Aujourd’hui pas de code (C’est assez rare pour le souligner Sourire ), juste quelques réflexions sur des questions qu’on me pose souvent.

Voici un condensé de ce qu’il faut savoir sur l’exposition des données, sur l’utilisation de divers API issues de divers SDK, de diverses spécifications Sourire

Concernant les applications WinRT, et même d’une manière générale, il est vrai qu’aujourd’hui on fait beaucoup moins de SOAP. J’entends bien sur des nouveaux projets, où on a le choix Sourire 
C’est un effet de mode, le SOAP n’a plus la côte, clairement le manque de lisibilité et simplicité est arrivé à bout de souffle dans l’esprit des développeurs.

Aujourd’hui on est plus basé sur une architecture REST, qui privilégie la simplicité de requêtage et le retour en JSON / XML. (Clairement JSON d’ailleurs)
Associé avec la spécification OData ( https://www.odata.org ) , le combo REST + OData couvre l’aspect nomenclature et exposition des metadatas, permettant de couvrir le scope de SOAP en son temps.

Du coup, si on part de ce constat là, voilà les différentes solutions pour travailler avec REST

Attention, je ne couvre que les scénarios On Premises (je n’aborderai pas le sujet Azure ici)

Coté serveur, exposer des données REST-ful peut se faire via :

  1. WCF webHttpBinding : Méthode de base. On expose des services, c’est vraiment du WCF bas niveau, donc pas mal de choses à coder, mais au moins, on maitrise tout, autant messages que services exposés.
  2. WCF Data Services : SDK d’implémentation de OData. Simple à mettre en œuvre, peu de code à écrire, prend en charge OData v1 à V3 : Attention, l’encapsulation et la facilité de mise en place peut limiter la customisation coté serveur de vos services. Encore que personnellement, je n’ai jamais été limité dans mes scénarios avec l’ensemble des API proposées.
  3. Web API : Implémentation haut niveau du modèle REST, embarqué dans une application WEB (ou OWIN https://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana ) : On se situe entre webHttpBinding et WCFData Services, au niveau customisation. C’est clairement aujourd’hui la méthodologie qui a la cote chez les développeurs Backend.

On sent clairement aujourd’hui que c’est Web API qui est la méthode d’avenir, et qui sera le plus à même d’évoluer.
Son intégration dans Visual Studio en fait l’outil à privilégier aujourd’hui.

De son coté, WCF Data Services va être proposé en Open Source. (https://blogs.msdn.com/b/odatateam/archive/2014/03/27/future-direction-of-wcf-data-services.aspx )

Web API est la seule solution aujourd’hui pour exposer du OData V4. Personnellement mes projets tournent en OData V3 avec WCF Data Services. Je n’ai pas encore eu le besoin de migrer vers V4, mais je vais entamer la migration prochainement.

Coté client, pour attaquer des données REST-ful, on peut :

  1. Partager les entités de bases (classes à sérialiser) entre le projet serveur et client via une Portable Class Library. Méthode la plus couramment utilisée.
    • L’appel des services se fera via un appel depuis HttpClient (voir plus loin le point HttpClient).
  2. Générer des proxys via le Add Reference, à partir du moment où on expose les métadatas, donc à partir du moment où le flux est du OData
    • Le SDK WCF Data Services coté client va permettre de générer les proxys si on attaque du OData V3 et se charger de faire les appels Web.
  3. Si le flux exposé est du OData V4, on passe par un partage PCL et via un module d’extension Visual Studio (OData Client Generator https://blogs.msdn.com/b/odatateam/archive/2014/03/11/how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class.aspx) qui va générer le proxy Client grâce à un template T4. On génère toujours un proxy mais pas via le Add Référence de Visual Studio.

Encore une fois, la génération automatique de proxy par Visual Studio n’a plus la cote aujourd’hui et on sent que la combo Portable Class Library + HttpClient est semble-t-il la solution la plus à même de couvrir l’ensemble des scénarios /plateformes

C’est d’ailleurs la seule solution aujourd’hui si on travaille avec des Universals Apps.

Concernant HttpClient :

Si vous êtes sur WinRT (Windows 8+ ou Windows Phone 8.1), il existe deux HttpClient :

  1. System.Net.Http.HttpClient
  2. Windows.Web.Http.HttpClient

Le premier est historique, issu de la migration .NET

Il vaut mieux utiliser le deuxième HttpClient (Namespace Windows.Web.Http) il permet de nombreux scénarios (Cache, Filtre etc …)

C’est clairement une bonne stratégie quitte à migrer de System.Net.Http.Client vers Windows.Web.Http.HttpClient

Voilà quelques pointeurs sur le sujet HttpClient :

  1. Une session Techdays 2014 animé par Eric Vernié, Loic Rebours et moi-même, où je traite justement le sujet HttpClient : https://www.microsoft.com/france/mstechdays/programmes/2014/fiche-session.aspx?ID=476ac3a2-c30e-401e-9a1b-3c579e63c9a7
  2. https://channel9.msdn.com/Events/Build/2013/4-092 : Five Great Reasons to Use the New HttpClient API to Connect to Web Services

Il existe aussi une version HttpClient PCL, qui permet d’avoir une classe partageable entre .NET et WinRT.

Utile quand on cible une application partageant du code entre le monde .NET et WinRT ou ciblant du Windows Phone 8.0

  1. https://blogs.msdn.com/b/bclteam/archive/2013/02/18/portable-httpclient-for-net-framework-and-windows-phone.aspx
  2. https://www.nuget.org/packages/Microsoft.Net.Http

 

Voilà mon avis sur le sujet, j’espère que c’est assez clair Sourire

Seb