Introduction aux protocoles enfichables
Le Microsoft .NET Framework fournit une implémentation en couche des services Internet, extensible et managée, qui peut être rapidement et facilement intégrée à vos applications. Les classes d'accès à Internet des espaces de noms System.Net et System.Net.Sockets peuvent être utilisées pour implémenter aussi bien les applications Web que les applications Internet.
Applications Internet
Généralement, les applications Internet peuvent être classées en deux catégories : les applications clientes qui demandent des informations et les applications serveur qui répondent aux demandes d'informations des clients. L'application client-serveur Internet classique est le World Wide Web, sur lequel les navigateurs permettent d'accéder aux documents et autres données stockés sur les serveurs Web à travers le monde.
Les applications ne se limitent pas uniquement à l'un de ces rôles ; par exemple, le serveur d'application de couche intermédiaire habituel répond aux demandes des clients en demandant les données auprès d'un autre serveur, auquel cas il se comporte à la fois comme serveur et comme client.
L'application cliente fait une demande en identifiant la ressource Internet demandée et le protocole de communication à utiliser pour la demande et la réponse. Si nécessaire, le client fournit aussi les données supplémentaires requises pour compléter la demande, comme l'emplacement du proxy ou les informations d'authentification (nom d'utilisateur, mot de passe, etc.). Une fois que la demande est complète, elle peut être envoyée au serveur.
Identification des ressources
Le .NET Framework utilise l'identificateur URI (Uniform Resource Identifier) pour identifier la ressource Internet demandée et le protocole de communication. L'identificateur URI se compose au moins de trois, voire quatre fragments : l'identificateur de modèle, qui identifie le protocole de communication de la demande et de la réponse ; l'identificateur de serveur, qui se compose d'un nom DNS (Domain Name System) d'hôte ou d'une adresse TCP qui identifie de façon unique le serveur sur Internet ; l'identificateur de chemin d'accès, qui localise les informations demandées sur le serveur ; et enfin, une chaîne de requête facultative, qui passe les informations du client au serveur. Par exemple, l'identificateur URI « https://www.contoso.com/whatsnew.aspx?date=today » se compose de l'identificateur de modèle « http », de l'identificateur de serveur « www.contoso.com », du chemin d'accès « /whatsnew.aspx » et de la chaîne de requête « ?date=today ».
Une fois que le serveur a reçu la demande et traité la réponse, il retourne la réponse à l'application cliente. La réponse contient des informations supplémentaires, comme le type de contenu (texte brut ou données XML, par exemple).
Demandes et réponses dans le .NET Framework
Le .NET Framework utilise des classes spécifiques pour fournir les trois informations requises pour accéder aux ressources Internet via un modèle demande/réponse : la classe Uri, qui contient l'identificateur URI de la ressource Internet recherchée, la classe WebRequest, qui contient la demande de la ressource et la classe WebResponse, qui fournit un conteneur pour la réponse entrante.
Les applications clientes créent des instances de WebRequest en passant l'identificateur URI de la ressource réseau à la méthode WebRequest.Create. Cette méthode static crée WebRequest pour un protocole particulier, comme le protocole HTTP. Le WebRequest retourné fournit l'accès aux propriétés qui contrôlent à la fois la demande faite au serveur et l'accès au flux de données envoyé lors de la demande. La méthode GetResponse sur WebRequest envoie la demande de l'application cliente vers le serveur identifié dans l'URI. Dans les cas où la réponse risquerait d'être retardée, la demande peut être faite de façon asynchrone à l'aide de la méthode BeginGetResponse sur WebRequest et la réponse peut être retournée ultérieurement à l'aide de la méthode EndGetResponse.
Les méthodes GetResponse et EndGetResponse retournent WebResponse qui fournit l'accès aux données retournées par le serveur. Comme ces données sont fournies à l'application qui émet la demande sous forme de flux par la méthode GetResponseStream, elles peuvent être utilisées dans une application à n'importe quel endroit où les flux de données sont utilisés.
Les classes WebRequest et WebResponse constituent la base des protocoles enfichables - implémentation de services réseau qui vous permet de développer des applications utilisant des ressources Internet sans que vous ayez à vous préoccuper des détails propres au protocole utilisé par chaque ressource. Les classes descendantes de WebRequest sont inscrites avec la classe WebRequest pour manager les détails de l'établissement des connexions réelles aux ressources Internet.
Par exemple, la classe HttpWebRequest manage les détails de la connexion à une ressource Internet à l'aide du protocole HTTP. Par défaut, quand la méthode WebRequest.Create rencontre un URI commençant par « http: » ou par « https: » (identificateurs des protocoles HTTP et HTTP sécurisé), le WebRequest retourné peut être utilisé tel quel ou vous pouvez effectuer un cast de type en HttpWebRequest pour accéder aux propriétés spécifiques au protocole. Dans la plupart des cas, WebRequest fournit toutes les informations nécessaires pour faire une demande.
Tout protocole pouvant être représenté sous la forme d'une transaction demande/réponse peut être utilisé dans WebRequest. Vous pouvez dériver des classes spécifiques au protocole à partir de WebRequest et WebResponse, puis les inscrire pour qu'elles soient utilisées par l'application avec la méthode static WebRequest.RegisterPrefix.
Quand l'autorisation client des demandes Internet est requise, la propriété Credentials de WebRequest fournit les informations d'authentification nécessaires. Ces informations d'authentification peuvent consister en une simple paire nom/mot de passe dans le cas d'une authentification de base HTTP ou Digest, ou en un ensemble nom/mot de passe/domaine dans le cas d'une authentification NTLM ou Kerberos. Un seul ensemble d'informations d'authentification peut être stocké dans une instance NetworkCredentials, ou plusieurs ensembles peuvent être stockés simultanément dans une instance CredentialCache. CredentialCache utilise l'identificateur URI de la demande et le schéma d'authentification que le serveur prend en charge pour déterminer les informations d'authentification qui doivent être envoyées au serveur.
Demandes simples avec WebClient
Pour les applications qui ont besoin de faire des demandes simples de ressources Internet, la classe WebClient fournit les méthodes communes permettant de télécharger les données vers ou à partir d'un serveur Internet. WebClient s'appuie sur la classe WebRequest pour fournir l'accès aux ressources Internet ; en conséquence, la classe WebClient peut utiliser n'importe quel protocole enfichable inscrit.
Pour les applications qui ne peuvent pas utiliser le modèle demande/réponse, ou pour celles qui ont besoin d'écouter sur le réseau et d'envoyer des demandes, l'espace de noms System.Net.Sockets fournit les classes TCPClient, TCPListener et UDPClient. Ces classes gèrent les détails de l'établissement des connexions à l'aide de différents protocoles de transport et exposent la connexion réseau à l'application sous la forme d'un flux.
Les développeurs qui connaissent bien l'interface Windows Sockets ou ceux qui ont besoin du contrôle fourni par programmation au niveau du socket constateront que les classes System.Net.Sockets répondent à leurs attentes. Les classes System.Net.Sockets constituent un point de transition entre le code managé et le code natif des classes System.Net. Dans la plupart des cas, les classes System.Net.Sockets marshalent les données dans leurs équivalents Windows 32 bits et gèrent tous les contrôles de sécurité nécessaires.