Calls

Http client 的工作是接收请求和生成响应。这个在原理上很简答的问题，在实现时变得很棘手。

Requests

每个 Http request 包含一个 URL，一个方法（例如 ：GET or Post），和 Headers 列表。Requests 也有可能包含一个请求体 ：一个具体内容的数据流。

Responses

一个 Response 应答 一个 Request 时，包含一个响应码（例如 200 成功 或者 404 未找到），headers，和自定义的响应体。

Rewriting Requests

当你提供一个 OkHttp 包含一个 Http request，你正在描述一个高级的请求：“取走我包含 Headers 的 Url “ 。为了正确高效，OkHttp 封装了 Request 在发出请求之前。

OkHttp 可能添加 headers，这些 headers 可能在原始的请求中是不存在的， 包括 Content-Length, Transfer-Encoding, User-Agent, Host, Connection, and Content-Type.他会自行添加一个Accept-Encoding header 给透明压缩的

响应，除非这个 header 已经存在了。如果你获取过 Cookies , OkHttp 会添加一个 Cookie header 包含他们。

一些 Requests 会有 Response 缓存。当缓存的响应没有更新时，OkHttp 会执行一个附加条件的 get 去下载一个更新过的 Response 如果它更新了。这些请求会添加 headers ，例如 If-Modified-Since和If-None-Match。

Rewriting Responses

如果使用透明压缩，OkHttp将删除相应的响应头Content-Encoding和Content-Length，因为它们不适用于解压缩的响应主体。

如果条件GET成功，则根据规范合并来自网络和缓存的响应。

Follow-up Requests

当你请求的 url 发生了转移 , web server 会返回 302 去指出文件的新路径。OkHttp 会跟踪重定向取取回最终的 Response 。

如果响应发出授权验证，OkHttp 会询问 Authenticator （如果已经配置过了）来通过授权验证。如果验证者提供了凭证，request 会带着这个凭证再次请求。

Retrying Requests

有时候会连接失败：不论是连接池失效了无法连接，还是 webserver 无法访问。OkHttp 会重新请求一个其他的路线，如果存在可用的。

Calls

通过重写，重定向，后续跟踪和重试，您的简单请求可能会产生许多请求和响应。OkHttp 使用 Call 来模拟满足您的请求的任务，但是许多中间的请求和响应时必要的。通常这不是很多！但是，如果您的URL被重定向或者故障转移到备用IP地址，您的代码将继续有效，这一点令人欣慰。

Calls 有两种执行方式：

• Synchronous ： 阻塞线程直到 Response 可读。
• Asynchronous ： 在任何线程上排队请求，当 response 可读时，在其他线程上获得回调。

Call 可以从任何线程取消。如果当前没有完成，Call 会失败！正在编写请求正文或读取响应正文的代码在 Call 被取消时将产生 IOException。

Dispatch

对于同步调用，您可以自己创建线程，并负责管理您同时发出的请求数。同时连接太多会浪费资源;太少会加长延迟。

对于异步调用，Dispatcher实现最大同时请求的策略。您可以设置每个网络服务器的最大值（默认值为5）和总体（默认值为64）。

生词

• This is simple in theory but it gets tricky in practice.
• a data stream of a specific content type.
• its own optional body.
• For correctness and efficiency, OkHttp rewrites your request before transmitting it.
• OkHttp may add headers that are absent from the original request.
• It will add an Accept-Encoding header for transparent response compression unless the header is already present.
• OkHttp will drop the corresponding response headers Content-Encoding and Content-Length
• they don’t apply to the decompressed response body.
• responses from the network and cache are merged as directed by the spec.
• the webserver will return a response code like 302 to indicate the document’s new URL.
• OkHttp will follow the redirect to retrieve a final response.
• If the response issues an authorization challenge, OkHttp will ask the Authenticator (if one is configured) to satisfy the challenge.
• If the authenticator supplies a credential, the request is retried with that credential included.
• Sometimes connections fail: either a pooled connection was stale and disconnected, or the webserver itself couldn’t be reached.
• With rewrites, redirects, follow-ups and retries, your simple request may yield many requests and responses.
• OkHttp uses Call to model the task of satisfying your request through however many intermediate requests and responses are necessary.
• Typically this isn’t many!
• But it’s comforting to know that your code will continue to work if your URLs are redirected or if you failover to an alternate IP address.
• Too many simultaneous connections wastes resources; too few harms latency.

原文：https://github.com/square/okhttp/wiki/Calls