Supports standard libraries and OSS. httphttpclient for underlying HttpClient reconstruction and encapsulation of oss. Http

Supports standard libraries and OSS. httphttpclient for underlying HttpClient reconstruction and encapsulation of oss. Http

The OSS. Http project's support for the. Net Standard library has been migrated, and the two bottom-layer libraries of the OSS open-source series have the ability to support cross-runtime. Because the OSS. Http class library is a lightweight Http request framework that I completed a few years ago with reference to the RestSharp idea. HttpWebRequest is still used at the underlying layer for a long time. This is basically a full reconstruction. This article mainly includes 1. HttpClient introduction, 2. refactoring ideas, and 3. problems that are easy to encounter.

1. Basic Introduction to httpclient

HttpClient should be in. the new functions referenced by the net framework4.5 and later versions are commonly used HttpWebRequest. In comparison, the former is simpler and clearer, and the most important is full support. net standard API, which is also an important reason for me to choose it.

The HttpClient structure has been greatly adjusted and is completely asynchronous. It can be said that asynchronous support has been completed from the underlying layer. Here we will first introduce the corresponding main classes:

1. HtttpRequestMessage

The basic information of the request, the request address, and the request action. The value is in the HttpClient method. When the parameter is passed in, the response is HttpResponseMessage.

2. HttpContent

The content body of the request, including the specific content of the request, contenttype, contentlenght, and so on. It is an attribute of HtttpRequestMessage. Both of them contain Headers attributes, but their ranges are different, this is easy to confuse and make mistakes. I have made a simple classification:

HttpRequestMessage headers are mainly request attributes, such as Accept, UserAgent, and AcceptEncoding.

HttpContent header (HttpContentHeaders) is mainly the attributes of the current request Content, 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 the definition of request content processing actions, such as whether redirection is supported, whether cookies can be used, Proxy, etc., which is biased towards system settings, you can pass this value through the HttpClient constructor. The default subclass provided by the system is HttpClientHandler.

4. HttpClient

The specific request implementation and call implementation fully implement the POST, GET, Delete and other Http request methods. All the methods finally call the SendAsync method.

 

The above four main classes constitute the main implementation of HttpClient requests. If you are simply using HttpClient, you only need to care about HttpClient, as shown below:

In fact, HttpRequestMessage and HttpClientHandler are assigned by default.

Although this is a brief introduction, we can basically see that the implementation of HttpClient has a very clear division of labor, rather than all the previous settings are concentrated in webrequest. The most direct advantage of a clear division of labor is that HttpClient achieves multi-request sharing. 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 the system, you can share an HttpClient, instead of redefining an object for every request like HttpWebReqest to reduce resource consumption.

 

2. Rebuilding OSS. Http

Return to the topic and refactor our current Code module, as I said, because. net Standard does not support httpWebRequest at all, which directly leads to a re-implementation decision. Because the previous httpWebRequest was simple, I basically made a large encapsulation framework, the upper layer does not need to be exposed to the specific underlying implementation, basically implementing the core of RestSharp. If you are interested, you can refer to the Code OSS. the Old branch under Http.

Before reconstruction, because I didn't know much about HttpClient, I wanted to continue the existing framework process and implement the conversion. However, with the research on the Client documentation, we found that many packages are not needed at all and the process has changed. Therefore, we deleted a lot of things in the original framework and reorganized the final implementation.

Of course, the current HttpClient implementation is simple and clear enough, but in many cases, directly calling POST, GET and other methods will reduce the reuse of some code, such as in OSS. in the Social project, the underlying layer only needs to implement a RestCommon method to achieve global Request control. The caller only needs to provide Url, HttpMothed, and Parameter.

Here I drew a simple flowchart for presentation:

 

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

In 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 implementation of the current encapsulation class. To ensure that HttpClient itself has a common function, OsRest inherits from HttpClient and provides the RestSend method, complete the process implementation in this method and finally call the SendAsync method to execute the request.

The RestUtil. cs auxiliary class completes global OsRest (HttpClient) Sharing and defines a default HttpClientHandler implementation. You can call this class normally.

 

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

Iii. Problems easily encountered

Although there is not much code after the entire refactoring, there are still some problems to share with you.

1. For more information about Header assignment, see section 1. Make sure to differentiate Headers. Otherwise, an incorrect value error may be reported.

2. we can see that the above flowchart has a "Get" judgment, because if it is a Get request, Content cannot be assigned a value, just as in HttpWebReqest, if the get request calls the GetRequestStream method, there will be an exception error "cannot send content body with this predicate type. Of course, if you are using OSS. Http as a request, then there will be no such problem.

 

3. The form parameters uploaded at the same time as the uploaded file are different from those submitted for separate form parameters. Please note that you can handle them without understanding the OsRest class.

 

If you have other questions or are interested in subsequent updates, follow the Public Account (OSSCoder ):