Terminez la reconstruction et l'encapsulation du HttpClient sous-jacent d'OSS.Http et prenez en charge l'introduction détaillée de la bibliothèque standard.

La prise en charge du projet OSS.Http pour la bibliothèque standard .Net Standard a été migrée et les deux bibliothèques de classes de niveau le plus bas de la série open source OSS ont déjà la capacité de prendre en charge plusieurs environnements d'exécution. Cet article comprend principalement 1. Introduction à HttpClient, 2. Idées de reconstruction, 3. Problèmes faciles à rencontrer. Il a une très bonne valeur de référence, jetons un œil avec l'éditeur ci-dessous

Le support du projet OSS.Http pour la bibliothèque standard .Net Standard a été migré, et les deux bibliothèques de classes de niveau le plus bas de l'OSS des séries open source sont déjà disponibles. La possibilité de prendre en charge tous les environnements d'exécution. Parce que la bibliothèque de classes OSS.Http est un framework de requêtes HTTP léger que j'ai complété il y a quelques années sur la base des idées de RestSharp. Parce que la couche inférieure utilise HttpWebRequest depuis longtemps, cette fois, elle est fondamentalement complètement refactorisée. Cet article comprend principalement 1. Introduction à HttpClient, 2. Idées de refactorisation, 3. Problèmes faciles à rencontrer.

1. Introduction de base à httpclient

HttpClient devrait être une nouvelle fonctionnalité référencée autour de la version 4.5 du framework .net. Avant cela, HttpWebRequest était couramment utilisé en comparaison. , le premier est plus simple et plus clair, et le plus important est qu'il prend entièrement en charge l'API standard .net. C'est aussi une raison importante pour laquelle je l'ai choisi.

HttpClient a effectué d'importants ajustements structurels et est une implémentation complètement asynchrone. On peut dire qu'il prend en charge le support asynchrone à partir de la couche inférieure :

1. HtttpRequestMessage

Informations de base de la demande, adresse de la demande, action de la demande, etc. Cette valeur est transmise en tant que paramètre dans la méthode HttpClient initiant une demande, et est identique à Il correspond au corps du contenu en réponse à la requête HttpResponseMessage

2, incluant principalement le contenu spécifique de. la requête, le type de contenu, la longueur du contenu, etc. C'est un attribut de HtttpRequestMessage. Les deux contiennent l'attribut Headers, mais la portée est différente. C'est un endroit où il est facile de se tromper et de faire des erreurs. classification : L'en-tête de HttpRequestMessage (HttpRequestHeaders) est principalement C'est l'attribut de la requête, tel que Accept, UserAgent, AcceptEncoding et d'autres attributs de base des liens http.

Les en-têtes de HttpContent (HttpContentHeaders) sont principalement des attributs du contenu de la requête actuelle, comprenant principalement : Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, etc. Pour plus de détails, voir la bibliothèque officielle de la classe.

Le système HttpContent fournit plusieurs implémentations par défaut, principalement les suivantes :

3. HttpMessageHandler

La fonction principale de cette classe est de définir les actions de traitement du contenu des requêtes, etc., telles que si la redirection est prise en charge, si les cookies peuvent être utilisés, le proxy proxy, etc. Elle est orientée vers les paramètres du système. y entrer via le constructeur HttpClient, la sous-classe fournie par le système par défaut est HttpClientHandler.

4. HttpClient

Implémentation d'appel d'implémentation de requête spécifique, implémentation complète de POST, GET, Delete et autres méthodes de requête Http, toutes les méthodes Le l'appel final est la méthode SendAsync. Les quatre classes principales ci-dessus constituent l'implémentation principale des requêtes HttpClient Si vous ne l'utilisez que simplement, vous n'avez qu'à vous soucier de HttpClient, comme suit :

<.>En fait, l'affectation de HttpRequestMessage et HttpClientHandler a été implémentée par défaut en son sein.

Bien que cela soit brièvement présenté, on peut voir en gros que l'implémentation de HttpClient a une division du travail très claire, et ce n'est plus comme avant que tous les paramètres soient concentrés dans webrequest. L'avantage le plus direct de la division claire du travail est que HttpClient peut être utilisé pour partager plusieurs requêtes. Voir l'article de blog :

Le HttpClient par défaut est le moyen le plus simple de commencer à envoyer des requêtes. peut être utilisé pour envoyer autant de requêtes HTTP que vous le souhaitez simultanément. Ainsi, dans de nombreux scénarios, vous pouvez simplement créer un seul HttpClient, puis l'utiliser pour toutes vos requêtes.

C'est-à-dire lorsque vous souhaitez lancer différentes requêtes dans votre système, vous pouvez partager un HttpClient au lieu de Like HttpWebReqest, fondamentalement, chaque requête doit redéfinir un objet pour réduire la consommation de ressources.

2. Refactoriser OSS.Http

Revenons au sujet, refactorisez notre module de code actuel Comme je l'ai dit, il n'est pas du tout fourni sous .Net Standard. La prise en charge de httpWebRequest m'a directement amené à prendre la décision de le réimplémenter. Parce que httpWebRequest était rudimentaire dans le passé, j'ai essentiellement créé un grand cadre d'encapsulation. La couche supérieure n'avait pas du tout besoin de toucher à l'implémentation sous-jacente spécifique. réalisé le noyau de RestSharp , les étudiants intéressés peuvent se référer à la branche Old sous le code OSS.Http.

Avant la reconstruction, parce que je ne connaissais pas grand-chose à HttpClient, je voulais continuer le processus de framework existant et convertir l'implémentation. Cependant, après avoir examiné et recherché les documents du client, j'ai découvert que de nombreuses encapsulations étaient complètement inutiles et que le processus avait également changé. J'ai donc supprimé de nombreux éléments du cadre d'origine et réorganisé l'implémentation finale.

Bien sûr, l'implémentation actuelle de HttpClient elle-même est assez simple et claire, mais dans de nombreux cas, appeler directement POST, GET et d'autres méthodes réduira la réutilisation de certains codes. Par exemple, dans le projet OSS.Social, je n'ai que cela. Vous devez implémenter une méthode RestCommon en bas, pour obtenir un contrôle global des requêtes, l'appelant n'a qu'à fournir Url, HttpMothed et Parameter.

Ici, j'ai dessiné un organigramme simple en guise de présentation :

Il n'y a fondamentalement pas de grande différence dans le processus. Le code est sur Github. du fichier est la suivante :

Sous le fichier Mos : classe d'énumération Enum.cs, classe de paramètres de fichier FileParameter.cs, classe de paramètres de formulaire FormParameter, classe de paramètres de requête OsHttpRequest,

OsRest. cs est la principale classe d'encapsulation actuellement implémentée, et afin de garantir que HttpClient lui-même possède des fonctions universelles, OsRest hérite de HttpClient et fournit également la méthode RestSend, dans laquelle le processus est terminé et la méthode SendAsync est finalement appelée pour exécuter la demande.

Classe auxiliaire RestUtil.cs, complète le partage de l'OsRest global (HttpClient) et définit une implémentation par défaut de HttpClientHandler. Vous pouvez simplement appeler cette classe directement.

Les paramètres d'exécution définis par l'utilisateur dans le processus peuvent être définis dans l'attribut délégué RequestSet dans OSHttpRequest. Par exemple, le type d'accès peut être défini sur json :

<.>

3. Des problèmes faciles à rencontrer

Bien qu'il n'y ait pas beaucoup de code après toute la reconstruction, il devrait quand même y avoir des problèmes qui peuvent être partagés avec tout le monde

1. Pour les problèmes d'affectation des en-têtes, veuillez vous référer à ma première partie. Assurez-vous de distinguer les différents en-têtes, sinon des erreurs de valeurs incorrectes pourraient vous être signalées

<.>

2. Vous pouvez constater qu'il y a un jugement sur « s'il s'agit de Get » dans l'organigramme ci-dessus, car s'il s'agit d'une requête Get, une valeur ne peut pas être attribuée au contenu, tout comme dans HttpWebReqest, si le get request appelle la méthode GetRequestStream, il y aura une erreur « Impossible d'envoyer une demande avec « Content-body » pour ce type de prédicat. Bien sûr, si vous utilisez OSS.Http comme requête, ce problème ne se posera pas.

3. Les paramètres du formulaire téléchargés en même temps que le fichier téléchargé sont différents des soumissions séparées des paramètres du formulaire. Veuillez faire attention à la manipulation et ne le faites pas. savoir comment faire référence à la classe OsRest Ça y est, c'est traité. Ce qui précède est l'introduction détaillée de la reconstruction et de l'encapsulation du HttpClient sous-jacent d'OSS.Http pour prendre en charge la bibliothèque standard. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois. (www.php.cn) !