Open Source projects: OkHttp – Implement OkHttp yourself

First, we assume that the network request library to be built is called WingjayHttpClient, so, as a network request library, what is its basic function?

Receive the user’s request -> send the request -> receive the response result and return it to the user.

So from the user’s perspective, what you need to do is:

1. To create aRequest: Set the destination URL inside; Request method, such as GET/POST. Some headers, such as Host and user-agent; If you upload a form in POST, you also need the body.
2. Will create goodRequestPassed to theWingjayHttpClient.
3. WingjayHttpClientTo carry outRequestAnd encapsulate the returned result into oneResponseTo the user. And aResponseIt should include statusCode like 200, some headers like Content-Type, maybe body

This is the beginning of a complete request. So let’s implement these three steps.

First, we need to create a Request class, using the Request class users can pass in their required parameters, the basic form is as follows:

class Request { String url; String method; Headers headers; Body requestBody; public Request(String url, String method, @Nullable Headers headers, @Nullable Body body) { this.url = url; . }}Copy the code

class WingjayHttpClient { ... private Response executeRequest(Request request) { Socket socket = new Socket(request.getUrl(), 80); ResponseData data = socket.connect().getResponseData(); return new Response(data); }... } class Response { int statusCode; Headers headers; Body responseBody ... }Copy the code

A simple user request is not enough to be an HTTP request. We need to add some headers to it. Such as Content-Length, Transfer-Encoding, user-Agent, Host, Connection, and Content-Type, if the request uses a cookie, So we’re also going to add cookies to this request.

We can extend the sendRequest(request) method above:

[class WingjayHttpClient]public Response sendRequest(Request userRequest) { Request httpRequest = expandHeaders(userRequest) return executeRequest(httpRequest)}private Request expandHeaders(Request userRequest) { if (userRequest.header("Connection") == null) { requestBuilder.header("Connection", "Keep-Alive") } if (userRequest.header("User-Agent") == null) { requestBuilder.header("User-Agent", Version.userAgent()) } ... }Copy the code

The so-called retry is very similar to redirection, that is, by judging the Response state, if the connection to the server fails, etc., then you can try to get a new path to reconnect. The general implementation is very similar to redirection, which will not be described here.

This is a very core part.

From the work above, we modified WingjayHttpClient to look like this:

class WingjayHttpClient { public Response sendRequest(Request userRequest) { Request httpRequest = expandHeaders(userRequest); Response response = executeRequest(httpRequest); switch (response.statusCode()) { case 300: case 301: case 302: case 303: case 307: case 308: return handleRedirect(response); default: return response; } } private Request expandHeaders(Request userRequest) {... } private Response executeRequest(Request httpRequest) {... } private Response handleRedirect(Response response) {... }}Copy the code

That is, WingjayHttpClient can now process individual requests synchronously.

However, in practice, a WingjayHttpClient may be used to process dozens of user requests at the same time, and these requests are divided into synchronous and asynchronous two different request modes. So we obviously can’t just stuff a request to WingjayHttpClient.

As we know, a request should be synchronous and asynchronous in addition to the HTTP protocol defined above. So where should this information be stored? There are two options:

1. Putting Request directly in is fine in theory, but defeats the purpose. We initially hoped to use Request to construct a Request that conforms to THE HTTP protocol, which should contain the destination URL of the Request, the Request port, the Request method and so on, and the HTTP protocol does not care whether the Request is synchronous or asynchronous information

2. It would be more appropriate to create a class that manages the state of the Request, so we can better split the responsibilities.

Therefore, we chose to create two classes, SyncCall and AsyncCall, to distinguish synchronous from asynchronous.

class SyncCall { private Request userRequest; public SyncCall(Request userRequest) { this.userRequest = userRequest; } } class AsyncCall { private Request userRequest; private Callback callback; public AsyncCall(Request userRequest, Callback callback) { this.userRequest = userRequest; this.callback = callback; } interface Callback { void onFailure(Call call, IOException e); void onResponse(Call call, Response response) throws IOException; }}Copy the code

Based on the above two classes, our usage scenarios are as follows:

WingjayHttpClient client = new WingjayHttpClient(); Request syncRequest = new Request("https://wingjay.com"); SyncCall syncCall = new SyncCall(request); Response response = client.sendSyncCall(syncCall); handle(response); AsyncCall asyncCall = new AsyncCall(request, new CallBack() { @Override public void onFailure(Call call, IOException e) {} @Override public void onResponse(Call call, Response response) throws IOException { handle(response); }}); client.equeueAsyncCall(asyncCall);Copy the code

As you can see from the above code, the responsibilities of WingjayHttpClient have changed: response = client.sendrequest (request); And now it is

response = client.sendSyncCall(syncCall);
client.equeueAsyncCall(asyncCall);
Copy the code

WingjayHttpClient needs to be modified as well. The basic idea is to add an internal request pool to manage all requests. So how do we design this request pool? There are two methods:

1. It is also theoretically possible to create several containers directly inside WingjayHttpClient. When the user passes (a)syncCall to the client, the client automatically stores the call into the corresponding container for management.

2. Creating a separate class to manage is obviously a better way to allocate responsibility. We define WingjayHttpClient’s responsibility as receiving a call, processing it internally and returning the result. This is the task of WingjayHttpClient, so how to manage the execution order and life cycle of these requests is not required by it.

Therefore, we create a new class: Dispatcher. This class does the following:

1. Store constantly incoming from the outside worldSyncCallandAsyncCallIf the user wants to cancel, the user can iterate over all the calls to perform the cancel operation.
2. forSyncCallSince it runs in real time, soDispatcherOnly need toSyncCallStore it before running and remove it after running.
3. forAsyncCall.DispatcherStart an ExecutorService and keep pulling it outAsyncCallThen, we set the maximum number of requests to 64. If 64 requests are already in progress, we store the asyncCall in the wait area.

According to the design, the Dispatcher structure can be obtained:

class Dispatcher { private final Deque runningSyncCalls = new ArrayDeque<>(); private int maxRequests = 64; private final Deque waitingAsyncCalls = new ArrayDeque<>(); private final Deque runningAsyncCalls = new ArrayDeque<>(); private ExecutorService executorService; public void startSyncCall(SyncCall syncCall) { runningSyncCalls.add(syncCall); } public void finishSyncCall(SyncCall syncCall) { runningSyncCalls.remove(syncCall); } public void enqueue(AsyncCall asyncCall) { if (runningAsyncCalls.size() < 64) { runningAsyncCalls.add(asyncCall); executorService.execute(asyncCall); } else { readyAsyncCalls.add(asyncCall); } } public void finishAsyncCall(AsyncCall asyncCall) { runningAsyncCalls.remove(asyncCall); }}Copy the code

So with this Dispatcher, we can modify WingjayHttpClient to do that

response = client.sendSyncCall(syncCall);
client.equeueAsyncCall(asyncCall);
Copy the code

These two methods. The concrete implementation is as follows

[class WingjayHttpClient]
	private Dispatcher dispatcher;
	public Response sendSyncCall(SyncCall syncCall) {
		try {
			// store syncCall into dispatcher;
			dispatcher.startSyncCall(syncCall);
			// execute
			return sendRequest(syncCall.getRequest());
		} finally {
			// remove syncCall from dispatcher
			dispatcher.finishSyncCall(syncCall);
		}
	}
	public void equeueAsyncCall(AsyncCall asyncCall) {
		// store asyncCall into dispatcher;
		dispatcher.enqueue(asyncCall);
		// it will be removed when this asyncCall be executed
	}
	Copy the code

Based on the above, we can handle both synchronous and asynchronous requests well. The application scenarios are as follows:

WingjayHttpClient client = new WingjayHttpClient(); Request syncRequest = new Request("https://wingjay.com"); SyncCall syncCall = new SyncCall(request); Response response = client.sendSyncCall(syncCall); handle(response); AsyncCall asyncCall = new AsyncCall(request, new CallBack() { @Override public void onFailure(Call call, IOException e) {} @Override public void onResponse(Call call, Response response) throws IOException { handle(response); }}); client.equeueAsyncCall(asyncCall);Copy the code