Complete the reconstruction and encapsulation of the underlying HttpClient of OSS.Http and support the detailed introduction of the standard library.

The OSS.Http project's support for the .Net Standard standard library has been migrated, and the two lowest-level class libraries in the OSS open source series already have the ability to support cross-runtime. This article mainly includes 1. Introduction to HttpClient, 2. Reconstruction ideas, 3. Problems that are easy to encounter. It has a very good reference value. Let’s take a look at it with the editor.

The OSS.Http project’s support for the .Net Standard standard library has been migrated, and the two lowest-level class libraries of the OSS open source series are already available. The ability to support across runtimes. Because the OSS.Http class library is a lightweight HTTP request framework that I completed a few years ago based on the ideas of RestSharp. Because the bottom layer has been using HttpWebRequest for a long time, this time it is basically completely refactored. This article mainly includes 1. Introduction to HttpClient, 2. Refactoring ideas, 3. Problems that are easy to encounter.

1. Basic introduction to httpclient

HttpClient should be a new feature referenced around .net framework version 4.5. Before that, HttpWebRequest was commonly used. In comparison In terms of performance, the former is simpler and clearer, and the most important thing is that it fully supports the .net standard API. This is also an important reason why I chose it.

HttpClient has made great structural adjustments and is a completely asynchronous implementation. It can be said that it has completed asynchronous support from the bottom layer. Here we first introduce the corresponding main classes:

1. HtttpRequestMessage

Basic information of the request, request address, request action, etc. This value is passed in as a parameter in the method of HttpClient initiating a request, and is the same as It corresponds to the content body that responds to HttpResponseMessage

2. HttpContent

request, mainly including the specific content of the request, contenttype, contentlenght, etc. It is an attribute of HtttpRequestMessage. Both of them contain the Headers attribute, but the scope is different. This is a place where confusion and error can easily occur. I have made a simple classification:

The header of HttpRequestMessage (HttpRequestHeaders) is mainly It is the attribute of the request, such as Accept, UserAgent, AcceptEncoding and other basic attributes of http links.

HttpContent headers (HttpContentHeaders) are mainly attributes of the current request content, mainly including: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, etc. For details, see the official class library .

The HttpContent system provides several default implementations, mainly as follows:

3. HttpMessageHandler

The main function of this class is to define the request content processing actions, such as whether redirection is supported, whether cookies can be used, proxy Proxy, etc. It is biased towards system settings. This value can be passed in through the HttpClient constructor. , the subclass provided by the system by default is HttpClientHandler.

4. HttpClient

Specific request implementation call implementation, complete implementation of POST, GET, Delete and other Http request methods, all methods The final call is the SendAsync method.

The four main classes above constitute the main implementation of HttpClient requests. If you only use it simply, you only need to care about HttpClient, as follows:

In fact, the assignment of HttpRequestMessage and HttpClientHandler has been implemented by default within it.

Although it is briefly introduced, it can basically be seen that the implementation of HttpClient has a very clear division of labor, and it is no longer like before that all settings are concentrated in webrequest. The most direct advantage of the clear division of labor is that HttpClient can be used to share multiple requests. See the blog post:

The default HttpClient is the simplest way in which you can start sending requests. A single HttpClient can be used to send as many HTTP requests as you want concurrently so in many scenarios you can just create one HttpClient and then use that for all your requests.

That is, when you want to initiate different requests in your system, you can share one HttpClient instead of Like HttpWebReqest, basically every request needs to redefine an object to reduce resource consumption.

2. Reconstruct OSS.Http

Back to the topic, reconstruct our current code module, as I said, because it is not provided at all under .Net Standard The support of httpWebRequest directly led me to make the decision to re-implement it. Because httpWebRequest was crude in the past, I basically made a large encapsulation framework. The upper layer did not need to touch the specific underlying implementation at all, and basically realized the core of RestSharp. , interested students can refer to the Old branch under the code OSS.Http.

Before the reconstruction, because I didn’t know much about HttpClient, I wanted to continue the existing framework process and convert the implementation. However, after reviewing and researching the Client documents, I found that many encapsulations were completely unnecessary and the process had also changed, so I deleted many things under the original framework and rearranged the final implementation.

Of course, the current implementation of HttpClient itself is simple and clear enough, but in many cases directly calling POST, GET and other methods will reduce the reuse of some codes. For example, in the OSS.Social project, I only need to implement a RestCommon method at the bottom , to achieve global request control, the caller only needs to provide Url, HttpMothed, and Parameter.

Here I drew a simple flow chart as a presentation:

There is basically no big difference in the process. The code is on Github, and the file structure is as follows:

Under the Mos file: Enum.cs enumeration class, FileParameter.cs file parameter class, FormParameter Form parameter class, OsHttpRequest request parameter class,

OsRest.cs is the main encapsulation class currently Implementation, and in order to ensure that HttpClient itself has universal functions, OsRest inherits from HttpClient and also provides the RestSend method, in which the process is completed and the SendAsync method is finally called to execute the request.

RestUtil.cs Auxiliary class, completes the sharing of global OsRest (HttpClient), and defines a default HttpClientHandler implementation. You can just call this class directly.

The execution user-defined settings in the process can be set in the RequestSet delegate attribute in OSHttpRequest. For example, the access type can be set to json:

3. Problems that are easy to encounter

Although there is not much code after the entire reconstruction, there should still be some problems that I can share with you

1. For Header assignment issues, please refer to my first part. Be sure to distinguish different Headers, otherwise you may be given incorrect value errors

2 . You can find that there is a judgment of "whether it is Get" in the flow chart above, because if it is a Get request, Content cannot be assigned a value, just like in HttpWebReqest, if the get request calls the GetRequestStream method, there will be "Unable to send a request with "Content-body" error for this predicate type. Of course, if you are using OSS.Http as the request, then there will be no such problem.

3. The form parameters uploaded at the same time as the uploaded file are different from the separate form parameter submissions. Please pay attention to the handling and do not know how to refer to the OsRest class. That’s it, it’s been processed.

The above is the detailed introduction to complete the reconstruction and encapsulation of the underlying HttpClient of OSS.Http and support the standard library. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!