HttpClientlink

大多数前端应用都需要通过 HTTP 协议与后端服务器通讯。现代浏览器支持使用两种不同的 API 发起 HTTP 请求：XMLHttpRequest 接口和 fetch() API。

Most front-end applications communicate with backend services over the HTTP protocol. Modern browsers support two different APIs for making HTTP requests: the XMLHttpRequest interface and the fetch() API.

@angular/common/http 中的 HttpClient 类为 Angular 应用程序提供了一个简化的 API 来实现 HTTP 客户端功能。它基于浏览器提供的 XMLHttpRequest 接口。 HttpClient 带来的其它优点包括：可测试性、强类型的请求和响应对象、发起请求与接收响应时的拦截器支持，以及更好的、基于可观察（Observable）对象的 API 以及流式错误处理机制。

The HttpClient in @angular/common/http offers a simplified client HTTP API for Angular applications that rests on the XMLHttpRequest interface exposed by browsers. Additional benefits of HttpClient include testability features, typed request and response objects, request and response interception, Observable apis, and streamlined error handling.

你可以到在线例子 / 下载范例中运行本章的代码。

You can run the在线例子 / 下载范例that accompanies this guide.

准备工作link

Setuplink

要想使用 HttpClient，就要先导入 Angular 的 HttpClientModule。大多数应用都会在根模块 AppModule 中导入它。

Before you can use the HttpClient, you need to import the Angular HttpClientModule. Most apps do so in the root AppModule.

      
        content_copy
      
      import { NgModule }         from '@angular/core';
import { BrowserModule }    from '@angular/platform-browser';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  imports: [
    BrowserModule,
    // import HttpClientModule after BrowserModule.
    HttpClientModule,
  ],
  declarations: [
    AppComponent,
  ],
  bootstrap: [ AppComponent ]
})
export class AppModule {}
    

在 AppModule 中导入 HttpClientModule 之后，你可以把 HttpClient 注入到应用类中，就像下面的 ConfigService 例子中这样。

Having imported HttpClientModule into the AppModule, you can inject the HttpClient into an application class as shown in the following ConfigService example.

      
        content_copy
      
      import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable()
export class ConfigService {
  constructor(private http: HttpClient) { }
}
    

获取 JSON 数据link

Getting JSON datalink

应用通常会从服务器上获取 JSON 数据。 比如，该应用可能要从服务器上获取配置文件 config.json，其中指定了一些特定资源的 URL。

Applications often request JSON data from the server. For example, the app might need a configuration file on the server, config.json, that specifies resource URLs.

      
        content_copy
      
      {
  "heroesUrl": "api/heroes",
  "textfile": "assets/textfile.txt"
}
    

ConfigService 会通过 HttpClient 的 get() 方法取得这个文件。

The ConfigService fetches this file with a get() method on HttpClient.

      
        content_copy
      
      configUrl = 'assets/config.json';

getConfig() {
  return this.http.get(this.configUrl);
}
    

像 ConfigComponent 这样的组件会注入 ConfigService，并调用其 getConfig 方法。

A component, such as ConfigComponent, injects the ConfigService and calls the getConfig service method.

      
        content_copy
      
      showConfig() {
  this.configService.getConfig()
    .subscribe((data: Config) => this.config = {
        heroesUrl: data['heroesUrl'],
        textfile:  data['textfile']
    });
}
    

这个服务方法返回配置数据的 Observable 对象，所以组件要订阅（subscribe） 该方法的返回值。 订阅时的回调函数会把这些数据字段复制到组件的 config 对象中，它会在组件的模板中绑定，以供显示。

Because the service method returns an Observable of configuration data, the component subscribes to the method's return value. The subscription callback copies the data fields into the component's config object, which is data-bound in the component template for display.

为什么要写服务link

Why write a servicelink

这个例子太简单，所以它也可以在组件本身的代码中调用 Http.get()，而不用借助服务。

This example is so simple that it is tempting to write the Http.get() inside the component itself and skip the service.

不过，数据访问很少能一直这么简单。 你通常要对数据做后处理、添加错误处理器，还可能加一些重试逻辑，以便应对网络抽风的情况。

However, data access rarely stays this simple. You typically post-process the data, add error handling, and maybe some retry logic to cope with intermittent connectivity.

该组件很快就会因为这些数据方式的细节而变得杂乱不堪。 组件变得难以理解、难以测试，并且这些数据访问逻辑无法被复用，也无法标准化。

The component quickly becomes cluttered with data access minutia. The component becomes harder to understand, harder to test, and the data access logic can't be re-used or standardized.

这就是为什么最佳实践中要求把数据展现逻辑从数据访问逻辑中拆分出去，也就是说把数据访问逻辑包装进一个单独的服务中， 并且在组件中把数据访问逻辑委托给这个服务。就算是这么简单的应用也要如此。

That's why it is a best practice to separate presentation of data from data access by encapsulating data access in a separate service and delegating to that service in the component, even in simple cases like this one.

带类型检查的响应link

Type-checking the responselink

该订阅的回调需要用通过括号中的语句来提取数据的值。

The subscribe callback above requires bracket notation to extract the data values.

      
        content_copy
      
      .subscribe((data: Config) => this.config = {
    heroesUrl: data['heroesUrl'],
    textfile:  data['textfile']
});
    

你没法写成 data.heroesUrl ，因为 TypeScript 会报告说来自服务器的 data 对象中没有名叫 heroesUrl 的属性。

You can't write data.heroesUrl because TypeScript correctly complains that the data object from the service does not have a heroesUrl property.

这是因为 HttpClient.get() 方法把 JSON 响应体解析成了匿名的 Object 类型。它不知道该对象的具体形态如何。

The HttpClient.get() method parsed the JSON server response into the anonymous Object type. It doesn't know what the shape of that object is.

你可以告诉 HttpClient 该响应体的类型，以便在消费这种输出时更容易、更明确。

You can tell HttpClient the type of the response to make consuming the output easier and more obvious.

首先，定义一个具有正确形态的接口：

First, define an interface with the correct shape:

      
        content_copy
      
      export interface Config {
  heroesUrl: string;
  textfile: string;
}
    

然后，在服务器中把该接口指定为 HttpClient.get() 调用的类型参数。

Then, specify that interface as the HttpClient.get() call's type parameter in the service:

      
        content_copy
      
      getConfig() {
  // now returns an Observable of Config
  return this.http.get<Config>(this.configUrl);
}
    

修改后的组件方法，其回调函数中获取一个带类型的对象，它易于使用，且消费起来更安全：

The callback in the updated component method receives a typed data object, which is easier and safer to consume:

      
        content_copy
      
      config: Config;

showConfig() {
  this.configService.getConfig()
    // clone the data object, using its known Config shape
    .subscribe((data: Config) => this.config = { ...data });
}
    

读取完整的响应体link

Reading the full responselink

响应体可能并不包含你需要的全部信息。有时候服务器会返回一个特殊的响应头或状态码，以标记出特定的条件，因此读取它们可能是必要的。

The response body doesn't return all the data you may need. Sometimes servers return special headers or status codes to indicate certain conditions that are important to the application workflow.

要这样做，你就要通过 observe 选项来告诉 HttpClient，你想要完整的响应信息，而不是只有响应体：

Tell HttpClient that you want the full response with the observe option:

      
        content_copy
      
      getConfigResponse(): Observable<HttpResponse<Config>> {
  return this.http.get<Config>(
    this.configUrl, { observe: 'response' });
}
    

现在 HttpClient.get() 会返回一个 HttpResponse 类型的 Observable，而不只是 JSON 数据。

Now HttpClient.get() returns an Observable of typed HttpResponse rather than just the JSON data.

该组件的 showConfigResponse() 方法会像显示配置数据一样显示响应头：

The component's showConfigResponse() method displays the response headers as well as the configuration:

      
        content_copy
      
      showConfigResponse() {
  this.configService.getConfigResponse()
    // resp is of type `HttpResponse<Config>`
    .subscribe(resp => {
      // display its headers
      const keys = resp.headers.keys();
      this.headers = keys.map(key =>
        `${key}: ${resp.headers.get(key)}`);

      // access the body directly, which is typed as `Config`.
      this.config = { ... resp.body };
    });
}
    

如你所见，该响应对象具有一个带有正确类型的 body 属性。

As you can see, the response object has a body property of the correct type.

错误处理link

Error handlinglink

如果这个请求导致了服务器错误怎么办？甚至，在烂网络下请求都没到服务器该怎么办？HttpClient 就会返回一个错误（error）而不再是成功的响应。

What happens if the request fails on the server, or if a poor network connection prevents it from even reaching the server? HttpClient will return an error object instead of a successful response.

通过在 .subscribe() 中添加第二个回调函数，你可以在组件中处理它：

You could handle in the component by adding a second callback to the .subscribe():

      
        content_copy
      
      showConfig() {
  this.configService.getConfig()
    .subscribe(
      (data: Config) => this.config = { ...data }, // success path
      error => this.error = error // error path
    );
}
    

在数据访问失败时给用户一些反馈，确实是个好主意。 不过，直接显示由 HttpClient 返回的原始错误数据还远远不够。

It's certainly a good idea to give the user some kind of feedback when data access fails. But displaying the raw error object returned by HttpClient is far from the best way to do it.

获取错误详情link

Getting error detailslink

检测错误的发生是第一步，不过如果知道具体发生了什么错误才会更有用。上面例子中传给回调函数的 err 参数的类型是 HttpErrorResponse，它包含了这个错误中一些很有用的信息。

Detecting that an error occurred is one thing. Interpreting that error and composing a user-friendly response is a bit more involved.

可能发生的错误分为两种。如果后端返回了一个失败的返回码（如 404、500 等），它会返回一个错误响应体。

Two types of errors can occur. The server backend might reject the request, returning an HTTP response with a status code such as 404 or 500. These are error responses.

或者，如果在客户端这边出了错误（比如在 RxJS 操作符 (operator) 中抛出的异常或某些阻碍完成这个请求的网络错误），就会抛出一个 Error 类型的异常。

Or something could go wrong on the client-side such as a network error that prevents the request from completing successfully or an exception thrown in an RxJS operator. These errors produce JavaScript ErrorEvent objects.

HttpClient 会在 HttpErrorResponse 中捕获所有类型的错误信息，你可以查看这个响应体以了解到底发生了什么。

The HttpClient captures both kinds of errors in its HttpErrorResponse and you can inspect that response to figure out what really happened.

错误的探查、解释和解决是你应该在服务中做的事情，而不是在组件中。

Error inspection, interpretation, and resolution is something you want to do in the service, not in the component.

你可能首先要设计一个错误处理器，就像这样：

You might first devise an error handler like this one:

      
        content_copy
      
      private handleError(error: HttpErrorResponse) {
  if (error.error instanceof ErrorEvent) {
    // A client-side or network error occurred. Handle it accordingly.
    console.error('An error occurred:', error.error.message);
  } else {
    // The backend returned an unsuccessful response code.
    // The response body may contain clues as to what went wrong,
    console.error(
      `Backend returned code ${error.status}, ` +
      `body was: ${error.error}`);
  }
  // return an observable with a user-facing error message
  return throwError(
    'Something bad happened; please try again later.');
};
    

注意，该处理器返回一个带有用户友好的错误信息的 RxJS ErrorObservable对象。 该服务的消费者期望服务的方法返回某种形式的 Observable，就算是“错误的”也可以。

Notice that this handler returns an RxJS ErrorObservablewith a user-friendly error message. Consumers of the service expect service methods to return an Observable of some kind, even a "bad" one.

现在，你获取了由 HttpClient 方法返回的 Observable，并把它们通过管道传给错误处理器。

Now you take the Observables returned by the HttpClient methods and pipe them through to the error handler.

      
        content_copy
      
      getConfig() {
  return this.http.get<Config>(this.configUrl)
    .pipe(
      catchError(this.handleError)
    );
}
    

retry()link

有时候，错误只是临时性的，只要重试就可能会自动消失。 比如，在移动端场景中可能会遇到网络中断的情况，只要重试一下就能拿到正确的结果。

Sometimes the error is transient and will go away automatically if you try again. For example, network interruptions are common in mobile scenarios, and trying again may produce a successful result.

RxJS 库提供了几个 retry 操作符，它们值得仔细看看。 其中最简单的是 retry()，它可以对失败的 Observable 自动重新订阅几次。对 HttpClient 方法调用的结果进行重新订阅会导致重新发起 HTTP 请求。

The RxJS library offers several retry operators that are worth exploring. The simplest is called retry() and it automatically re-subscribes to a failed Observable a specified number of times. Re-subscribing to the result of an HttpClient method call has the effect of reissuing the HTTP request.

把它插入到 HttpClient 方法结果的管道中，就放在错误处理器的紧前面。

Pipe it onto the HttpClient method result just before the error handler.

      
        content_copy
      
      getConfig() {
  return this.http.get<Config>(this.configUrl)
    .pipe(
      retry(3), // retry a failed request up to 3 times
      catchError(this.handleError) // then handle the error
    );
}
    

可观察对象 (Observable) 与操作符 (operator)link

Observables and operatorslink

本章的前一节中引用了 RxJS 的 Observable 和 operator，比如 catchError 和 retry。 接下来你还会遇到更多 RxJS 中的概念。

The previous sections of this guide referred to RxJS Observables and operators such as catchError and retry. You will encounter more RxJS artifacts as you continue below.

RxJS 是一个库，用于把异步调用和基于回调的代码组合成函数式（functional）的、响应式（reactive）的风格。 很多 Angular API，包括 HttpClient 都会生成和消费 RxJS 的 Observable。

RxJS is a library for composing asynchronous and callback-based code in a functional, reactive style. Many Angular APIs, including HttpClient, produce and consume RxJS Observables.

RxJS 本身超出了本章的范围。你可以在网络上找到更多的学习资源。 虽然只用少量的 RxJS 知识就可以获得解决方案，不过以后你会逐步提高 RxJS 技能，以便更高效的使用 HttpClient。

RxJS itself is out-of-scope for this guide. You will find many learning resources on the web. While you can get by with a minimum of RxJS knowledge, you'll want to grow your RxJS skills over time in order to use HttpClient effectively.

如果你在跟着教程敲下面这些代码片段，要注意你要自己导入这里出现的 RxJS 的可观察对象和操作符。就像 ConfigService 中的这些导入。

If you're following along with these code snippets, note that you must import the RxJS observable and operator symbols that appear in those snippets. These ConfigService imports are typical.

      
        content_copy
      
      import { Observable, throwError } from 'rxjs';
import { catchError, retry } from 'rxjs/operators';
    

请求非 JSON 格式的数据link

Requesting non-JSON datalink

不是所有的 API 都会返回 JSON 数据。在下面这个例子中，DownloaderService 中的方法会从服务器读取文本文件， 并把文件的内容记录下来，然后把这些内容使用 Observable<string> 的形式返回给调用者。

Not all APIs return JSON data. In this next example, a DownloaderService method reads a text file from the server and logs the file contents, before returning those contents to the caller as an Observable<string>.

      
        content_copy
      
      getTextFile(filename: string) {
  // The Observable returned by get() is of type Observable<string>
  // because a text response was specified.
  // There's no need to pass a <string> type parameter to get().
  return this.http.get(filename, {responseType: 'text'})
    .pipe(
      tap( // Log the result or error
        data => this.log(filename, data),
        error => this.logError(filename, error)
      )
    );
}
    

这里的 HttpClient.get() 返回字符串而不是默认的 JSON 对象，因为它的 responseType 选项是 'text'。

HttpClient.get() returns a string rather than the default JSON because of the responseType option.

RxJS 的 tap 操作符（可看做 wiretap - 窃听），让这段代码探查由可观察对象传过来的正确值和错误值，而不用打扰它们。

The RxJS tap operator (as in "wiretap") lets the code inspect good and error values passing through the observable without disturbing them.

在 DownloaderComponent 中的 download() 方法通过订阅这个服务中的方法来发起一次请求。

A download() method in the DownloaderComponent initiates the request by subscribing to the service method.

      
        content_copy
      
      download() {
  this.downloaderService.getTextFile('assets/textfile.txt')
    .subscribe(results => this.contents = results);
}
    

把数据发送到服务器link

Sending data to the serverlink

除了从服务器获取数据之外，HttpClient 还支持修改型的请求，也就是说，通过 PUT、POST、DELETE 这样的 HTTP 方法把数据发送到服务器。

In addition to fetching data from the server, HttpClient supports mutating requests, that is, sending data to the server with other HTTP methods such as PUT, POST, and DELETE.

本指南中的这个范例应用包括一个简化版本的《英雄指南》，它会获取英雄数据，并允许用户添加、删除和修改它们。

The sample app for this guide includes a simplified version of the "Tour of Heroes" example that fetches heroes and enables users to add, delete, and update them.

下面的这些章节中包括该范例的 HeroesService 中的一些方法片段。

The following sections excerpt methods of the sample's HeroesService.

添加请求头link

Adding headerslink

很多服务器在进行保存型操作时需要额外的请求头。 比如，它们可能需要一个 Content-Type 头来显式定义请求体的 MIME 类型。 也可能服务器会需要一个认证用的令牌（token）。

Many servers require extra headers for save operations. For example, they may require a "Content-Type" header to explicitly declare the MIME type of the request body. Or perhaps the server requires an authorization token.

HeroesService 在 httpOptions 对象中就定义了一些这样的请求头，并把它传给每个 HttpClient 的保存型方法。

The HeroesService defines such headers in an httpOptions object that will be passed to every HttpClient save method.

      
        content_copy
      
      import { HttpHeaders } from '@angular/common/http';

const httpOptions = {
  headers: new HttpHeaders({
    'Content-Type':  'application/json',
    'Authorization': 'my-auth-token'
  })
};
    

发起一个 POST 请求link

Making a POST requestlink

应用经常把数据 POST 到服务器。它们会在提交表单时进行 POST。 下面这个例子中，HeroesService 在把英雄添加到数据库中时，就会使用 POST。

Apps often POST data to a server. They POST when submitting a form. In the following example, the HeroesService posts when adding a hero to the database.

      
        content_copy
      
      /** POST: add a new hero to the database */
addHero (hero: Hero): Observable<Hero> {
  return this.http.post<Hero>(this.heroesUrl, hero, httpOptions)
    .pipe(
      catchError(this.handleError('addHero', hero))
    );
}
    

HttpClient.post() 方法像 get() 一样也有类型参数（你会希望服务器返回一个新的英雄对象），它包含一个资源 URL。

The HttpClient.post() method is similar to get() in that it has a type parameter (you're expecting the server to return the new hero) and it takes a resource URL.

它还接受另外两个参数：

It takes two more parameters:

1. hero - 要 POST 的请求体数据。

   hero - the data to POST in the body of the request.

2. httpOptions - 这个例子中，该方法的选项指定了所需的请求头。

   httpOptions - the method options which, in this case, specify required headers.

当然，它捕获错误的方式很像前面描述的操作方式。

Of course it catches errors in much the same manner described above.

HeroesComponent 通过订阅该服务方法返回的 Observable 发起了一次实际的 POST 操作。

The HeroesComponent initiates the actual POST operation by subscribing to the Observable returned by this service method.

      
        content_copy
      
      this.heroesService.addHero(newHero)
  .subscribe(hero => this.heroes.push(hero));
    

当服务器成功做出响应时，会带有这个新创建的英雄，然后该组件就会把这个英雄添加到正在显示的 heroes 列表中。

When the server responds successfully with the newly added hero, the component adds that hero to the displayed heroes list.

发起 DELETE 请求link

Making a DELETE requestlink

该应用可以把英雄的 id 传给 HttpClient.delete 方法的请求 URL 来删除一个英雄。

This application deletes a hero with the HttpClient.delete method by passing the hero's id in the request URL.

      
        content_copy
      
      /** DELETE: delete the hero from the server */
deleteHero (id: number): Observable<{}> {
  const url = `${this.heroesUrl}/${id}`; // DELETE api/heroes/42
  return this.http.delete(url, httpOptions)
    .pipe(
      catchError(this.handleError('deleteHero'))
    );
}
    

当 HeroesComponent 订阅了该服务方法返回的 Observable 时，就会发起一次实际的 DELETE 操作。

The HeroesComponent initiates the actual DELETE operation by subscribing to the Observable returned by this service method.

      
        content_copy
      
      this.heroesService.deleteHero(hero.id).subscribe();
    

该组件不会等待删除操作的结果，所以它的 subscribe （订阅）中没有回调函数。不过就算你不关心结果，也仍然要订阅它。调用 subscribe() 方法会执行这个可观察对象，这时才会真的发起 DELETE 请求。

The component isn't expecting a result from the delete operation, so it subscribes without a callback. Even though you are not using the result, you still have to subscribe. Calling the subscribe() method executes the observable, which is what initiates the DELETE request.

      
        content_copy
      
      // oops ... subscribe() is missing so nothing happens
this.heroesService.deleteHero(hero.id);
    

别忘了订阅！

Always subscribe!

在调用方法返回的可观察对象的 subscribe() 方法之前，HttpClient 方法不会发起 HTTP 请求。这适用于 HttpClient 的所有方法。

An HttpClient method does not begin its HTTP request until you call subscribe() on the observable returned by that method. This is true for all HttpClient methods.

HttpClient 的所有方法返回的可观察对象都设计为冷的。 HTTP 请求的执行都是延期执行的，让你可以用 tap 和 catchError 这样的操作符来在实际执行什么之前，先对这个可观察对象进行扩展。

All observables returned from HttpClient methods are cold by design. Execution of the HTTP request is deferred, allowing you to extend the observable with additional operations such as tap and catchError before anything actually happens.

调用 subscribe(...) 会触发这个可观察对象的执行，并导致 HttpClient 组合并把 HTTP 请求发给服务器。

Calling subscribe(...) triggers execution of the observable and causes HttpClient to compose and send the HTTP request to the server.

你可以把这些可观察对象看做实际 HTTP 请求的蓝图。

You can think of these observables as blueprints for actual HTTP requests.

      
        content_copy
      
      const req = http.get<Heroes>('/api/heroes');
// 0 requests made - .subscribe() not called.
req.subscribe();
// 1 request made.
req.subscribe();
// 2 requests made.
    

发起 PUT 请求link

Making a PUT requestlink

应用可以发送 PUT 请求，来使用修改后的数据完全替换掉一个资源。 下面的 HeroesService 例子和 POST 的例子很像。

An app will send a PUT request to completely replace a resource with updated data. The following HeroesService example is just like the POST example.

      
        content_copy
      
      /** PUT: update the hero on the server. Returns the updated hero upon success. */
updateHero (hero: Hero): Observable<Hero> {
  return this.http.put<Hero>(this.heroesUrl, hero, httpOptions)
    .pipe(
      catchError(this.handleError('updateHero', hero))
    );
}
    

因为前面解释过的原因，调用者（这里是 HeroesComponent.update()）必须 subscribe() 由 HttpClient.put() 返回的可观察对象，以发起这个调用。

For the reasons explained above, the caller (HeroesComponent.update() in this case) must subscribe() to the observable returned from the HttpClient.put() in order to initiate the request.

高级用法link

Advanced usagelink

我们已经讨论了 @angular/common/http 的基本 HTTP 功能，但有时候除了单纯发起请求和取回数据之外，你还要再做点别的。

We have discussed the basic HTTP functionality in @angular/common/http, but sometimes you need to do more than make simple requests and get data back.

配置请求link

Configuring the requestlink

待发送请求的其它方面可以通过传给 HttpClient 方法的最后一个参数指定的配置对象进行配置。

Other aspects of an outgoing request can be configured via the options object passed as the last argument to the HttpClient method.

以前你曾在 HeroesService 中通过在其保存方法中传入配置对象 httpOptions 设置过默认头。 你还可以做更多。

You saw earlier that the HeroesService sets the default headers by passing an options object (httpOptions) to its save methods. You can do more.

修改这些头link

Update headerslink

你没法直接修改前述配置对象中的现有头，因为这个 HttpHeaders 类的实例是不可变的。

You can't directly modify the existing headers within the previous options object because instances of the HttpHeaders class are immutable.

改用 set() 方法代替。 它会返回当前实例的一份克隆，其中应用了这些新修改。

Use the set() method instead. It returns a clone of the current instance with the new changes applied.

比如在发起下一个请求之前，如果旧的令牌已经过期了，你可能还要修改认证头。

Here's how you might update the authorization header (after the old token expired) before making the next request.

      
        content_copy
      
      httpOptions.headers =
  httpOptions.headers.set('Authorization', 'my-new-auth-token');
    

URL 参数link

URL Parameterslink

添加 URL 搜索参数也与此类似。 这里的 searchHeroes 方法会查询名字中包含搜索词的英雄列表。

Adding URL search parameters works a similar way. Here is a searchHeroes method that queries for heroes whose names contain the search term.

      
        content_copy
      
      /* GET heroes whose name contains search term */
searchHeroes(term: string): Observable<Hero[]> {
  term = term.trim();

  // Add safe, URL encoded search parameter if there is a search term
  const options = term ?
   { params: new HttpParams().set('name', term) } : {};

  return this.http.get<Hero[]>(this.heroesUrl, options)
    .pipe(
      catchError(this.handleError<Hero[]>('searchHeroes', []))
    );
}
    

如果有搜索词，这段代码就会构造一个包含进行过 URL 编码的搜索词的选项对象。如果这个搜索词是“foo”，这个 GET 请求的 URL 就会是 api/heroes/?name=foo。

If there is a search term, the code constructs an options object with an HTML URL-encoded search parameter. If the term were "foo", the GET request URL would be api/heroes/?name=foo.

HttpParams 是不可变的，所以你也要使用 set() 方法来修改这些选项。

The HttpParams are immutable so you'll have to use the set() method to update the options.

请求的防抖（debounce）link

Debouncing requestslink

这个例子还包含了搜索 npm 包的特性。

The sample includes an npm package search feature.

当用户在搜索框中输入名字时，PackageSearchComponent 就会把一个根据名字搜索包的请求发送给 NPM 的 web api。

When the user enters a name in a search-box, the PackageSearchComponent sends a search request for a package with that name to the NPM web API.

下面是模板中的相关代码片段：

Here's a pertinent excerpt from the template:

      
        content_copy
      
      <input (keyup)="search($event.target.value)" id="name" placeholder="Search"/>

<ul>
  <li *ngFor="let package of packages$ | async">
    <b>{{package.name}} v.{{package.version}}</b> -
    <i>{{package.description}}</i>
  </li>
</ul>
    

(keyup) 事件绑定把每次击键都发送给了组件的 search() 方法。

The (keyup) event binding sends every keystroke to the component's search() method.

如果每次击键都发送一次请求就太昂贵了。 最好能等到用户停止输入时才发送请求。 使用 RxJS 的操作符就能轻易实现它，参见下面的代码片段：

Sending a request for every keystroke could be expensive. It's better to wait until the user stops typing and then send a request. That's easy to implement with RxJS operators, as shown in this excerpt.

      
        content_copy
      
      
withRefresh = false;
packages$: Observable<NpmPackageInfo[]>;
private searchText$ = new Subject<string>();
 
search(packageName: string) {
  this.searchText$.next(packageName);
}
 
ngOnInit() {
  this.packages$ = this.searchText$.pipe(
    debounceTime(500),
    distinctUntilChanged(),
    switchMap(packageName =>
      this.searchService.search(packageName, this.withRefresh))
  );
}
 
constructor(private searchService: PackageSearchService) { }
    

searchText$ 是一个序列，包含用户输入到搜索框中的所有值。 它定义成了 RxJS 的 Subject 对象，这表示它是一个多播 Observable，同时还可以自行调用 next(value) 来产生值。 search() 方法中就是这么做的。

The searchText$ is the sequence of search-box values coming from the user. It's defined as an RxJS Subject, which means it is a multicasting Observable that can also produce values for itself by calling next(value), as happens in the search() method.

除了把每个 searchText 的值都直接转发给 PackageSearchService 之外，ngOnInit() 中的代码还通过下列三个操作符对这些搜索值进行管道处理：

Rather than forward every searchText value directly to the injected PackageSearchService, the code in ngOnInit() pipes search values through three operators:

1. debounceTime(500) - 等待，直到用户停止输入（这个例子中是停止 1/2 秒）。

   debounceTime(500) - wait for the user to stop typing (1/2 second in this case).

2. distinctUntilChanged() - 等待，直到搜索内容发生了变化。

   distinctUntilChanged() - wait until the search text changes.

3. switchMap() - 把搜索请求发送给服务。

   switchMap() - send the search request to the service.

这些代码把 packages$ 设置成了使用搜索结果组合出的 Observable 对象。 模板中使用 AsyncPipe 订阅了 packages$，一旦搜索结果的值发回来了，就显示这些搜索结果。

The code sets packages$ to this re-composed Observable of search results. The template subscribes to packages$ with the AsyncPipe and displays search results as they arrive.

这样，只有当用户停止了输入且搜索值和以前不一样的时候，搜索值才会传给服务。

A search value reaches the service only if it's a new value and the user has stopped typing.

switchMap()link

这个 switchMap() 操作符有三个重要的特征：

The switchMap() operator has three important characteristics.

1. 它的参数是一个返回 Observable 的函数。PackageSearchService.search 会返回 Observable，其它数据服务也一样。

   It takes a function argument that returns an Observable. PackageSearchService.search returns an Observable, as other data service methods do.

2. 如果以前的搜索结果仍然是在途状态（这会出现在慢速网络中），它会取消那个请求，并发起一次新的搜索。

   If a previous search request is still in-flight (as when the connection is poor), it cancels that request and sends a new one.

3. 它会按照原始的请求顺序返回这些服务的响应，而不用关心服务器实际上是以乱序返回的它们。

   It returns service responses in their original request order, even if the server returns them out of order.

拦截请求和响应link

Intercepting requests and responseslink

HTTP 拦截机制是 @angular/common/http 中的主要特性之一。 使用这种拦截机制，你可以声明一些拦截器，用它们监视和转换从应用发送到服务器的 HTTP 请求。 拦截器还可以用监视和转换从服务器返回到本应用的那些响应。 多个选择器会构成一个“请求/响应处理器”的双向链表。

HTTP Interception is a major feature of @angular/common/http. With interception, you declare interceptors that inspect and transform HTTP requests from your application to the server. The same interceptors may also inspect and transform the server's responses on their way back to the application. Multiple interceptors form a forward-and-backward chain of request/response handlers.

拦截器可以用一种常规的、标准的方式对每一次 HTTP 的请求/响应任务执行从认证到记日志等很多种隐式任务。

Interceptors can perform a variety of implicit tasks, from authentication to logging, in a routine, standard way, for every HTTP request/response.

如果没有拦截机制，那么开发人员将不得不对每次 HttpClient 调用显式实现这些任务。

Without interception, developers would have to implement these tasks explicitly for each HttpClient method call.

编写拦截器link

Write an interceptorlink

要实现拦截器，就要实现一个实现了 HttpInterceptor 接口中的 intercept() 方法的类。

To implement an interceptor, declare a class that implements the intercept() method of the HttpInterceptor interface.

这里是一个什么也不做的空白拦截器，它只会不做任何修改的传递这个请求。

Here is a do-nothing noop interceptor that simply passes the request through without touching it:

      
        content_copy
      
      import { Injectable } from '@angular/core';
import {
  HttpEvent, HttpInterceptor, HttpHandler, HttpRequest
} from '@angular/common/http';

import { Observable } from 'rxjs';

/** Pass untouched request through to the next request handler. */
@Injectable()
export class NoopInterceptor implements HttpInterceptor {

  intercept(req: HttpRequest<any>, next: HttpHandler):
    Observable<HttpEvent<any>> {
    return next.handle(req);
  }
}
    

intercept 方法会把请求转换成一个最终返回 HTTP 响应体的 Observable。 在这个场景中，每个拦截器都完全能自己处理这个请求。

The intercept method transforms a request into an Observable that eventually returns the HTTP response. In this sense, each interceptor is fully capable of handling the request entirely by itself.

大多数拦截器拦截都会在传入时检查请求，然后把（可能被修改过的）请求转发给 next 对象的 handle() 方法，而 next 对象实现了 HttpHandler接口。

Most interceptors inspect the request on the way in and forward the (perhaps altered) request to the handle() method of the next object which implements the HttpHandlerinterface.

      
        content_copy
      
      export abstract class HttpHandler {
  abstract handle(req: HttpRequest<any>): Observable<HttpEvent<any>>;
}
    

像 intercept() 一样，handle() 方法也会把 HTTP 请求转换成 HttpEvents组成的 Observable，它最终包含的是来自服务器的响应。 intercept() 函数可以检查这个可观察对象，并在把它返回给调用者之前修改它。

Like intercept(), the handle() method transforms an HTTP request into an Observable of HttpEventswhich ultimately include the server's response. The intercept() method could inspect that observable and alter it before returning it to the caller.

这个无操作的拦截器，会直接使用原始的请求调用 next.handle()，并返回它返回的可观察对象，而不做任何后续处理。

This no-op interceptor simply calls next.handle() with the original request and returns the observable without doing a thing.

next 对象link

The next objectlink

next 对象表示拦截器链表中的下一个拦截器。 这个链表中的最后一个 next 对象就是 HttpClient 的后端处理器（backend handler），它会把请求发给服务器，并接收服务器的响应。

The next object represents the next interceptor in the chain of interceptors. The final next in the chain is the HttpClient backend handler that sends the request to the server and receives the server's response.

大多数的拦截器都会调用 next.handle()，以便这个请求流能走到下一个拦截器，并最终传给后端处理器。 拦截器也可以不调用 next.handle()，使这个链路短路，并返回一个带有人工构造出来的服务器响应的 自己的 Observable。

Most interceptors call next.handle() so that the request flows through to the next interceptor and, eventually, the backend handler. An interceptor could skip calling next.handle(), short-circuit the chain, and return its own Observablewith an artificial server response.

这是一种常见的中间件模式，在像 Express.js 这样的框架中也会找到它。

This is a common middleware pattern found in frameworks such as Express.js.

提供这个拦截器link

Provide the interceptorlink

这个 NoopInterceptor 就是一个由 Angular 依赖注入 (DI)系统管理的服务。 像其它服务一样，你也必须先提供这个拦截器类，应用才能使用它。

The NoopInterceptor is a service managed by Angular's dependency injection (DI) system. Like other services, you must provide the interceptor class before the app can use it.

由于拦截器是 HttpClient 服务的（可选）依赖，所以你必须在提供 HttpClient 的同一个（或其各级父注入器）注入器中提供这些拦截器。 那些在 DI 创建完 HttpClient 之后再提供的拦截器将会被忽略。

Because interceptors are (optional) dependencies of the HttpClient service, you must provide them in the same injector (or a parent of the injector) that provides HttpClient. Interceptors provided after DI creates the HttpClient are ignored.

由于在 AppModule 中导入了 HttpClientModule，导致本应用在其根注入器中提供了 HttpClient。所以你也同样要在 AppModule 中提供这些拦截器。

This app provides HttpClient in the app's root injector, as a side-effect of importing the HttpClientModule in AppModule. You should provide interceptors in AppModule as well.

在从 @angular/common/http 中导入了 HTTP_INTERCEPTORS 注入令牌之后，编写如下的 NoopInterceptor 提供商注册语句：

After importing the HTTP_INTERCEPTORS injection token from @angular/common/http, write the NoopInterceptor provider like this:

      
        content_copy
      
      { provide: HTTP_INTERCEPTORS, useClass: NoopInterceptor, multi: true },
    

注意 multi: true 选项。 这个必须的选项会告诉 Angular HTTP_INTERCEPTORS 是一个多重提供商的令牌，表示它会注入一个多值的数组，而不是单一的值。

Note the multi: true option. This required setting tells Angular that HTTP_INTERCEPTORS is a token for a multiprovider that injects an array of values, rather than a single value.

你也可以直接把这个提供商添加到 AppModule 中的提供商数组中，不过那样会非常啰嗦。况且，你将来还会用这种方式创建更多的拦截器并提供它们。 你还要特别注意提供这些拦截器的顺序。

You could add this provider directly to the providers array of the AppModule. However, it's rather verbose and there's a good chance that you'll create more interceptors and provide them in the same way. You must also pay close attention to the order in which you provide these interceptors.

认真考虑创建一个封装桶（barrel）文件，用于把所有拦截器都收集起来，一起提供给 httpInterceptorProviders 数组，可以先从这个 NoopInterceptor 开始。

Consider creating a "barrel" file that gathers all the interceptor providers into an httpInterceptorProviders array, starting with this first one, the NoopInterceptor.

      
        content_copy
      
      /* "Barrel" of Http Interceptors */
import { HTTP_INTERCEPTORS } from '@angular/common/http';

import { NoopInterceptor } from './noop-interceptor';

/** Http interceptor providers in outside-in order */
export const httpInterceptorProviders = [
  { provide: HTTP_INTERCEPTORS, useClass: NoopInterceptor, multi: true },
];
    

然后导入它，并把它加到 AppModule 的 providers 数组中，就像这样：

Then import and add it to the AppModule providers array like this:

      
        content_copy
      
      providers: [
  httpInterceptorProviders
],
    

当你再创建新的拦截器时，就同样把它们添加到 httpInterceptorProviders 数组中，而不用再修改 AppModule。

As you create new interceptors, add them to the httpInterceptorProviders array and you won't have to revisit the AppModule.

拦截器的顺序link

Interceptor orderlink

Angular 会按照你提供它们的顺序应用这些拦截器。 如果你提供拦截器的顺序是先 A，再 B，再 C，那么请求阶段的执行顺序就是 A->B->C，而响应阶段的执行顺序则是 C->B->A。

Angular applies interceptors in the order that you provide them. If you provide interceptors A, then B, then C, requests will flow in A->B->C and responses will flow out C->B->A.

以后你就再也不能修改这些顺序或移除某些拦截器了。 如果你需要动态启用或禁用某个拦截器，那就要在那个拦截器中自行实现这个功能。

You cannot change the order or remove interceptors later. If you need to enable and disable an interceptor dynamically, you'll have to build that capability into the interceptor itself.

HttpEventslink

你可能会期望 intercept() 和 handle() 方法会像大多数 HttpClient 中的方法那样返回 HttpResponse<any> 的可观察对象。

You may have expected the intercept() and handle() methods to return observables of HttpResponse<any> as most HttpClient methods do.

然而并没有，它们返回的是 HttpEvent<any> 的可观察对象。

Instead they return observables of HttpEvent<any>.

这是因为拦截器工作的层级比那些 HttpClient 方法更低一些。每个 HTTP 请求都可能会生成很多个事件，包括上传和下载的进度事件。 实际上，HttpResponse 类本身就是一个事件，它的类型（type）是 HttpEventType.HttpResponseEvent。

That's because interceptors work at a lower level than those HttpClient methods. A single HTTP request can generate multiple events, including upload and download progress events. The HttpResponse class itself is actually an event, whose type is HttpEventType.HttpResponseEvent.

很多拦截器只关心发出的请求，而对 next.handle() 返回的事件流不会做任何修改。

Many interceptors are only concerned with the outgoing request and simply return the event stream from next.handle() without modifying it.

但那些要检查和修改来自 next.handle() 的响应体的拦截器希望看到所有这些事件。 所以，你的拦截器应该返回你没碰过的所有事件，除非你有充分的理由不这么做。

But interceptors that examine and modify the response from next.handle() will see all of these events. Your interceptor should return every event untouched unless it has a compelling reason to do otherwise.

不可变性link

Immutabilitylink

虽然拦截器有能力改变请求和响应，但 HttpRequest 和 HttpResponse 实例的属性却是只读（readonly）的， 因此让它们基本上是不可变的。

Although interceptors are capable of mutating requests and responses, the HttpRequest and HttpResponse instance properties are readonly, rendering them largely immutable.

有充足的理由把它们做成不可变对象：应用可能会重试发送很多次请求之后才能成功，这就意味着这个拦截器链表可能会多次重复处理同一个请求。 如果拦截器可以修改原始的请求对象，那么重试阶段的操作就会从修改过的请求开始，而不是原始请求。 而这种不可变性，可以确保这些拦截器在每次重试时看到的都是同样的原始请求。

They are immutable for a good reason: the app may retry a request several times before it succeeds, which means that the interceptor chain may re-process the same request multiple times. If an interceptor could modify the original request object, the re-tried operation would start from the modified request rather than the original. Immutability ensures that interceptors see the same request for each try.

通过把 HttpRequest 的属性设置为只读的，TypeScript 可以防止你犯这种错误。

TypeScript will prevent you from setting HttpRequest readonly properties.

      
        content_copy
      
      // Typescript disallows the following assignment because req.url is readonly
req.url = req.url.replace('http://', 'https://');
    

要想修改该请求，就要先克隆它，并修改这个克隆体，然后再把这个克隆体传给 next.handle()。 你可以用一步操作中完成对请求的克隆和修改，例子如下：

To alter the request, clone it first and modify the clone before passing it to next.handle(). You can clone and modify the request in a single step as in this example.

      
        content_copy
      
      // clone request and replace 'http://' with 'https://' at the same time
const secureReq = req.clone({
  url: req.url.replace('http://', 'https://')
});
// send the cloned, "secure" request to the next handler.
return next.handle(secureReq);
    

这个 clone() 方法的哈希型参数允许你在复制出克隆体的同时改变该请求的某些特定属性。

The clone() method's hash argument allows you to mutate specific properties of the request while copying the others.

请求体link

The request bodylink

readonly 这种赋值保护，无法防范深修改（修改子对象的属性），也不能防范你修改请求体对象中的属性。

The readonly assignment guard can't prevent deep updates and, in particular, it can't prevent you from modifying a property of a request body object.

      
        content_copy
      
      req.body.name = req.body.name.trim(); // bad idea!
    

如果你必须修改请求体，那么就要先复制它，然后修改这个复本，clone() 这个请求，然后把这个请求体的复本作为新的请求体，例子如下：

If you must mutate the request body, copy it first, change the copy, clone() the request, and set the clone's body with the new body, as in the following example.

      
        content_copy
      
      // copy the body and trim whitespace from the name property
const newBody = { ...body, name: body.name.trim() };
// clone request and set its body
const newReq = req.clone({ body: newBody });
// send the cloned request to the next handler.
return next.handle(newReq);
    

清空请求体link

Clearing the request bodylink

有时你需要清空请求体，而不是替换它。 如果你把克隆后的请求体设置成 undefined，Angular 会认为你是想让这个请求体保持原样。 这显然不是你想要的。 但如果把克隆后的请求体设置成 null，那 Angular 就知道你是想清空这个请求体了。

Sometimes you need to clear the request body rather than replace it. If you set the cloned request body to undefined, Angular assumes you intend to leave the body as is. That is not what you want. If you set the cloned request body to null, Angular knows you intend to clear the request body.

      
        content_copy
      
      newReq = req.clone({ ... }); // body not mentioned => preserve original body
newReq = req.clone({ body: undefined }); // preserve original body
newReq = req.clone({ body: null }); // clear the body
    

设置默认请求头link

Set default headerslink

应用通常会使用拦截器来设置外发请求的默认请求头。

Apps often use an interceptor to set default headers on outgoing requests.

该范例应用具有一个 AuthService，它会生成一个认证令牌。 在这里，AuthInterceptor 会注入该服务以获取令牌，并对每一个外发的请求添加一个带有该令牌的认证头：

The sample app has an AuthService that produces an authorization token. Here is its AuthInterceptor that injects that service to get the token and adds an authorization header with that token to every outgoing request:

      
        content_copy
      
      
import { AuthService } from '../auth.service';
 
@Injectable()
export class AuthInterceptor implements HttpInterceptor {
 
  constructor(private auth: AuthService) {}
 
  intercept(req: HttpRequest<any>, next: HttpHandler) {
    // Get the auth token from the service.
    const authToken = this.auth.getAuthorizationToken();
 
    // Clone the request and replace the original headers with
    // cloned headers, updated with the authorization.
    const authReq = req.clone({
      headers: req.headers.set('Authorization', authToken)
    });
 
    // send cloned request with header to the next handler.
    return next.handle(authReq);
  }
}
    

这种在克隆请求的同时设置新请求头的操作太常见了，因此它还有一个快捷方式 setHeaders：

The practice of cloning a request to set new headers is so common that there's a setHeaders shortcut for it:

      
        content_copy
      
      // Clone the request and set the new header in one step.
const authReq = req.clone({ setHeaders: { Authorization: authToken } });
    

这种可以修改头的拦截器可以用于很多不同的操作，比如：

An interceptor that alters headers can be used for a number of different operations, including:

• 认证 / 授权

  Authentication/authorization

• 控制缓存行为。比如 If-Modified-Since

  Caching behavior; for example, If-Modified-Since

• XSRF 防护

  XSRF protection

记日志link

Logginglink

因为拦截器可以同时处理请求和响应，所以它们也可以对整个 HTTP 操作进行计时和记录日志。

Because interceptors can process the request and response together, they can do things like time and log an entire HTTP operation.

考虑下面这个 LoggingInterceptor，它捕获请求的发起时间、响应的接收时间，并使用注入的 MessageService 来发送总共花费的时间。

Consider the following LoggingInterceptor, which captures the time of the request, the time of the response, and logs the outcome with the elapsed time with the injected MessageService.

      
        content_copy
      
      
import { finalize, tap } from 'rxjs/operators';
import { MessageService } from '../message.service';
 
@Injectable()
export class LoggingInterceptor implements HttpInterceptor {
  constructor(private messenger: MessageService) {}
 
  intercept(req: HttpRequest<any>, next: HttpHandler) {
    const started = Date.now();
    let ok: string;
 
    // extend server response observable with logging
    return next.handle(req)
      .pipe(
        tap(
          // Succeeds when there is a response; ignore other events
          event => ok = event instanceof HttpResponse ? 'succeeded' : '',
          // Operation failed; error is an HttpErrorResponse
          error => ok = 'failed'
        ),
        // Log when response observable either completes or errors
        finalize(() => {
          const elapsed = Date.now() - started;
          const msg = `${req.method} "${req.urlWithParams}"
             ${ok} in ${elapsed} ms.`;
          this.messenger.add(msg);
        })
      );
  }
}
    

RxJS 的 tap 操作符会捕获请求成功了还是失败了。 RxJS 的 finalize 操作符无论在响应成功还是失败时都会调用（这是必须的），然后把结果汇报给 MessageService。

The RxJS tap operator captures whether the request succeed or failed. The RxJS finalize operator is called when the response observable either errors or completes (which it must), and reports the outcome to the MessageService.

在这个可观察对象的流中，无论是 tap 还是 finalize 接触过的值，都会照常发送给调用者。

Neither tap nor finalize touch the values of the observable stream returned to the caller.

缓存link

Cachinglink

拦截器还可以自行处理这些请求，而不用转发给 next.handle()。

Interceptors can handle requests by themselves, without forwarding to next.handle().

比如，你可能会想缓存某些请求和响应，以便提升性能。 你可以把这种缓存操作委托给某个拦截器，而不破坏你现有的各个数据服务。

For example, you might decide to cache certain requests and responses to improve performance. You can delegate caching to an interceptor without disturbing your existing data services.

CachingInterceptor 演示了这种方式。

The CachingInterceptor demonstrates this approach.

      
        content_copy
      
      @Injectable()
export class CachingInterceptor implements HttpInterceptor {
  constructor(private cache: RequestCache) {}

  intercept(req: HttpRequest<any>, next: HttpHandler) {
    // continue if not cachable.
    if (!isCachable(req)) { return next.handle(req); }

    const cachedResponse = this.cache.get(req);
    return cachedResponse ?
      of(cachedResponse) : sendRequest(req, next, this.cache);
  }
}
    

isCachable() 函数用于决定该请求是否允许缓存。 在这个例子中，只有发到 npm 包搜索 API 的 GET 请求才是可以缓存的。

The isCachable() function determines if the request is cachable. In this sample, only GET requests to the npm package search api are cachable.

如果该请求是不可缓存的，该拦截器只会把该请求转发给链表中的下一个处理器。

If the request is not cachable, the interceptor simply forwards the request to the next handler in the chain.

如果可缓存的请求在缓存中找到了，该拦截器就会通过 of() 函数返回一个已缓存的响应体的可观察对象，然后把它传给 next 处理器（以及所有其它下游拦截器）。

If a cachable request is found in the cache, the interceptor returns an of() observable with the cached response, by-passing the next handler (and all other interceptors downstream).

如果可缓存的请求在缓存中没找到，代码就会调用 sendRequest。

If a cachable request is not in cache, the code calls sendRequest.

      
        content_copy
      
      
/**
 * Get server response observable by sending request to `next()`.
 * Will add the response to the cache on the way out.
 */
function sendRequest(
  req: HttpRequest<any>,
  next: HttpHandler,
  cache: RequestCache): Observable<HttpEvent<any>> {
 
  // No headers allowed in npm search request
  const noHeaderReq = req.clone({ headers: new HttpHeaders() });
 
  return next.handle(noHeaderReq).pipe(
    tap(event => {
      // There may be other events besides the response.
      if (event instanceof HttpResponse) {
        cache.put(req, event); // Update the cache.
      }
    })
  );
}
    

sendRequest 函数创建了一个不带请求头的请求克隆体，因为 npm API 不会接受它们。

The sendRequest function creates a request clone without headers because the npm api forbids them.

它会把这个请求转发给 next.handle()，它最终会调用服务器，并且返回服务器的响应。

It forwards that request to next.handle() which ultimately calls the server and returns the server's response.

注意 sendRequest 是如何在发回给应用之前拦截这个响应的。 它会通过 tap() 操作符对响应进行管道处理，并在其回调中把响应加到缓存中。

Note how sendRequest intercepts the response on its way back to the application. It pipes the response through the tap() operator, whose callback adds the response to the cache.

然后，原始的响应会通过这些拦截器链，原封不动的回到服务器的调用者那里。

The original response continues untouched back up through the chain of interceptors to the application caller.

数据服务，比如 PackageSearchService，并不知道它们收到的某些 HttpClient 请求实际上是从缓存的请求中返回来的。

Data services, such as PackageSearchService, are unaware that some of their HttpClient requests actually return cached responses.

返回多值可观察对象link

Return a multi-valued Observablelink

HttpClient.get() 方法正常情况下只会返回一个可观察对象，它或者发出数据，或者发出错误。 有些人说它是“一次性完成”的可观察对象。

The HttpClient.get() method normally returns an observable that either emits the data or an error. Some folks describe it as a "one and done" observable.

但是拦截器也可以把这个修改成发出多个值的可观察对象。

But an interceptor can change this to an observable that emits more than once.

修改后的 CachingInterceptor 版本可以返回一个立即发出缓存的响应，然后仍然把请求发送到 NPM 的 Web API，然后再把修改过的搜索结果重新发出一次。

A revised version of the CachingInterceptor optionally returns an observable that immediately emits the cached response, sends the request to the NPM web API anyway, and emits again later with the updated search results.

      
        content_copy
      
      // cache-then-refresh
if (req.headers.get('x-refresh')) {
  const results$ = sendRequest(req, next, this.cache);
  return cachedResponse ?
    results$.pipe( startWith(cachedResponse) ) :
    results$;
}
// cache-or-fetch
return cachedResponse ?
  of(cachedResponse) : sendRequest(req, next, this.cache);
    

这种缓存并刷新的选项是由自定义的 x-refresh 头触发的。

The cache-then-refresh option is triggered by the presence of a custom x-refresh header.

修改后的 CachingInterceptor 会发起一个服务器请求，而不管有没有缓存的值。 就像 前面 的 sendRequest() 方法一样进行订阅。 在订阅 results$ 可观察对象时，就会发起这个请求。

The revised CachingInterceptor sets up a server request whether there's a cached value or not, using the same sendRequest() method described above. The results$ observable will make the request when subscribed.

如果没有缓存的值，拦截器直接返回 result$。

If there's no cached value, the interceptor returns results$.

如果有缓存的值，这些代码就会把缓存的响应加入到 result$ 的管道中，使用重组后的可观察对象进行处理，并发出两次。 先立即发出一次缓存的响应体，然后发出来自服务器的响应。 订阅者将会看到一个包含这两个响应的序列。

If there is a cached value, the code pipes the cached response onto results$, producing a recomposed observable that emits twice, the cached response first (and immediately), followed later by the response from the server. Subscribers see a sequence of two responses.

监听进度事件link

Listening to progress eventslink

有时，应用会传输大量数据，并且这些传输可能会花费很长时间。 典型的例子是文件上传。 可以通过在传输过程中提供进度反馈，来提升用户体验。

Sometimes applications transfer large amounts of data and those transfers can take a long time. File uploads are a typical example. Give the users a better experience by providing feedback on the progress of such transfers.

要想发起带有进度事件的请求，你可以创建一个把 reportProgress 选项设置为 true 的 HttpRequest 实例，以开启进度跟踪事件。

To make a request with progress events enabled, you can create an instance of HttpRequest with the reportProgress option set true to enable tracking of progress events.

      
        content_copy
      
      const req = new HttpRequest('POST', '/upload/file', file, {
  reportProgress: true
});
    

接下来，把这个请求对象传给 HttpClient.request() 方法，它返回一个 HttpEvents 的 Observable，同样也可以在拦截器中处理这些事件。

Next, pass this request object to the HttpClient.request() method, which returns an Observable of HttpEvents, the same events processed by interceptors:

      
        content_copy
      
      // The `HttpClient.request` API produces a raw event stream
// which includes start (sent), progress, and response events.
return this.http.request(req).pipe(
  map(event => this.getEventMessage(event, file)),
  tap(message => this.showProgress(message)),
  last(), // return last (completed) message to caller
  catchError(this.handleError(file))
);
    

getEventMessage 方法会解释事件流中的每一个 HttpEvent 类型。

The getEventMessage method interprets each type of HttpEvent in the event stream.

      
        content_copy
      
      /** Return distinct message for sent, upload progress, & response events */
private getEventMessage(event: HttpEvent<any>, file: File) {
  switch (event.type) {
    case HttpEventType.Sent:
      return `Uploading file "${file.name}" of size ${file.size}.`;

    case HttpEventType.UploadProgress:
      // Compute and show the % done:
      const percentDone = Math.round(100 * event.loaded / event.total);
      return `File "${file.name}" is ${percentDone}% uploaded.`;

    case HttpEventType.Response:
      return `File "${file.name}" was completely uploaded!`;

    default:
      return `File "${file.name}" surprising upload event: ${event.type}.`;
  }
}
    

安全：XSRF 防护link

Security: XSRF Protectionlink

跨站请求伪造 (XSRF)是一个攻击技术，它能让攻击者假冒一个已认证的用户在你的网站上执行未知的操作。HttpClient 支持一种通用的机制来防范 XSRF 攻击。当执行 HTTP 请求时，一个拦截器会从 cookie 中读取 XSRF 令牌（默认名字为 XSRF-TOKEN），并且把它设置为一个 HTTP 头 X-XSRF-TOKEN，由于只有运行在你自己的域名下的代码才能读取这个 cookie，因此后端可以确认这个 HTTP 请求真的来自你的客户端应用，而不是攻击者。

Cross-Site Request Forgery (XSRF) is an attack technique by which the attacker can trick an authenticated user into unknowingly executing actions on your website. HttpClient supports a common mechanism used to prevent XSRF attacks. When performing HTTP requests, an interceptor reads a token from a cookie, by default XSRF-TOKEN, and sets it as an HTTP header, X-XSRF-TOKEN. Since only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.

默认情况下，拦截器会在所有的修改型请求中（比如 POST 等）把这个 cookie 发送给使用相对 URL 的请求。但不会在 GET/HEAD 请求中发送，也不会发送给使用绝对 URL 的请求。

By default, an interceptor sends this cookie on all mutating requests (POST, etc.) to relative URLs but not on GET/HEAD requests or on requests with an absolute URL.

要获得这种优点，你的服务器需要在页面加载或首个 GET 请求中把一个名叫 XSRF-TOKEN 的令牌写入可被 JavaScript 读到的会话 cookie 中。 而在后续的请求中，服务器可以验证这个 cookie 是否与 HTTP 头 X-XSRF-TOKEN 的值一致，以确保只有运行在你自己域名下的代码才能发起这个请求。这个令牌必须对每个用户都是唯一的，并且必须能被服务器验证，因此不能由客户端自己生成令牌。把这个令牌设置为你的站点认证信息并且加了盐（salt）的摘要，以提升安全性。

To take advantage of this, your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on either the page load or the first GET request. On subsequent requests the server can verify that the cookie matches the X-XSRF-TOKEN HTTP header, and therefore be sure that only code running on your domain could have sent the request. The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens. Set the token to a digest of your site's authentication cookie with a salt for added security.

为了防止多个 Angular 应用共享同一个域名或子域时出现冲突，要给每个应用分配一个唯一的 cookie 名称。

In order to prevent collisions in environments where multiple Angular apps share the same domain or subdomain, give each application a unique cookie name.

配置自定义 cookie/header 名称link

Configuring custom cookie/header nameslink

如果你的后端服务中对 XSRF 令牌的 cookie 或 头使用了不一样的名字，就要使用 HttpClientXsrfModule.withConfig() 来覆盖掉默认值。

If your backend service uses different names for the XSRF token cookie or header, use HttpClientXsrfModule.withOptions() to override the defaults.

      
        content_copy
      
      imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'My-Xsrf-Cookie',
    headerName: 'My-Xsrf-Header',
  }),
],
    

测试 HTTP 请求link

Testing HTTP requestslink

如同所有的外部依赖一样，HTTP 后端也需要在良好的测试实践中被 Mock 掉。@angular/common/http 提供了一个测试库 @angular/common/http/testing，它让你可以直截了当的进行这种 Mock 。

Like any external dependency, the HTTP backend needs to be mocked so your tests can simulate interaction with a remote server. The @angular/common/http/testing library makes setting up such mocking straightforward.

Mock 方法论link

Mocking philosophylink

Angular 的 HTTP 测试库是专为其中的测试模式而设计的。在这种模式下，会首先在应用中执行代码并发起请求。

Angular's HTTP testing library is designed for a pattern of testing wherein the app executes code and makes requests first.

然后，每个测试会期待发起或未发起过某个请求，对这些请求进行断言， 最终对每个所预期的请求进行刷新（flush）来对这些请求提供响应。

Then a test expects that certain requests have or have not been made, performs assertions against those requests, and finally provide responses by "flushing" each expected request.

最终，测试可能会验证这个应用不曾发起过非预期的请求。

At the end, tests may verify that the app has made no unexpected requests.

搭建环境link

Setuplink

要开始测试那些通过 HttpClient 发起的请求，就要导入 HttpClientTestingModule 模块，并把它加到你的 TestBed 设置里去，代码如下：

To begin testing calls to HttpClient, import the HttpClientTestingModule and the mocking controller, HttpTestingController, along with the other symbols your tests require.

      
        content_copy
      
      // Http testing module and mocking controller
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';

// Other imports
import { TestBed } from '@angular/core/testing';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
    

然后把 HTTPClientTestingModule 添加到 TestBed 中，并继续设置被测服务。

Then add the HttpClientTestingModule to the TestBed and continue with the setup of the service-under-test.

      
        content_copy
      
      describe('HttpClient testing', () => {
  let httpClient: HttpClient;
  let httpTestingController: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [ HttpClientTestingModule ]
    });

    // Inject the http service and test controller for each test
    httpClient = TestBed.get(HttpClient);
    httpTestingController = TestBed.get(HttpTestingController);
  });
  /// Tests begin ///
});
    

现在，在测试中发起的这些请求会发给这些测试用的后端（testing backend），而不是标准的后端。

Now requests made in the course of your tests will hit the testing backend instead of the normal backend.

这种设置还会调用 TestBed.get()，来获取注入的 HttpClient 服务和模拟对象的控制器 HttpTestingController，以便在测试期间引用它们。

This setup also calls TestBed.get() to inject the HttpClient service and the mocking controller so they can be referenced during the tests.

期待并回复请求link

Expecting and answering requestslink

现在，你就可以编写测试，等待 GET 请求并给出模拟响应。

Now you can write a test that expects a GET Request to occur and provides a mock response.

      
        content_copy
      
      it('can test HttpClient.get', () => {
  const testData: Data = {name: 'Test Data'};

  // Make an HTTP GET request
  httpClient.get<Data>(testUrl)
    .subscribe(data =>
      // When observable resolves, result should match test data
      expect(data).toEqual(testData)
    );

  // The following `expectOne()` will match the request's URL.
  // If no requests or multiple requests matched that URL
  // `expectOne()` would throw.
  const req = httpTestingController.expectOne('/data');

  // Assert that the request is a GET.
  expect(req.request.method).toEqual('GET');

  // Respond with mock data, causing Observable to resolve.
  // Subscribe callback asserts that correct data was returned.
  req.flush(testData);

  // Finally, assert that there are no outstanding requests.
  httpTestingController.verify();
});
    

最后一步，验证没有发起过预期之外的请求，足够通用，因此你可以把它移到 afterEach() 中：

The last step, verifying that no requests remain outstanding, is common enough for you to move it into an afterEach() step:

      
        content_copy
      
      afterEach(() => {
  // After every test, assert that there are no more pending requests.
  httpTestingController.verify();
});
    

自定义对请求的预期link

Custom request expectationslink

如果仅根据 URL 匹配还不够，你还可以自行实现匹配函数。 比如，你可以验证外发的请求是否带有某个认证头：

If matching by URL isn't sufficient, it's possible to implement your own matching function. For example, you could look for an outgoing request that has an authorization header:

      
        content_copy
      
      // Expect one request with an authorization header
const req = httpTestingController.expectOne(
  req => req.headers.has('Authorization')
);
    

像前面的 expectOne() 测试一样，如果零或两个以上的请求满足了这个断言，它就会抛出异常。

As with the previous expectOne(), the test will fail if 0 or 2+ requests satisfy this predicate.

处理一个以上的请求link

Handling more than one requestlink

如果你需要在测试中对重复的请求进行响应，可以使用 match() API 来代替 expectOne()，它的参数不变，但会返回一个与这些请求相匹配的数组。一旦返回，这些请求就会从将来要匹配的列表中移除，你要自己验证和刷新（flush）它。

If you need to respond to duplicate requests in your test, use the match() API instead of expectOne(). It takes the same arguments but returns an array of matching requests. Once returned, these requests are removed from future matching and you are responsible for flushing and verifying them.

      
        content_copy
      
      // get all pending requests that match the given URL
const requests = httpTestingController.match(testUrl);
expect(requests.length).toEqual(3);

// Respond to each request with different results
requests[0].flush([]);
requests[1].flush([testData[0]]);
requests[2].flush(testData);
    

测试对错误的预期link

Testing for errorslink

你还要测试应用对于 HTTP 请求失败时的防护。

You should test the app's defenses against HTTP requests that fail.

调用 request.flush() 并传入一个错误信息，如下所示：

Call request.flush() with an error message, as seen in the following example.

      
        content_copy
      
      it('can test for 404 error', () => {
  const emsg = 'deliberate 404 error';

  httpClient.get<Data[]>(testUrl).subscribe(
    data => fail('should have failed with the 404 error'),
    (error: HttpErrorResponse) => {
      expect(error.status).toEqual(404, 'status');
      expect(error.error).toEqual(emsg, 'message');
    }
  );

  const req = httpTestingController.expectOne(testUrl);

  // Respond with mock error
  req.flush(emsg, { status: 404, statusText: 'Not Found' });
});
    

另外，你还可以使用 ErrorEvent 来调用 request.error().

Alternatively, you can call request.error() with an ErrorEvent.

      
        content_copy
      
      it('can test for network error', () => {
  const emsg = 'simulated network error';

  httpClient.get<Data[]>(testUrl).subscribe(
    data => fail('should have failed with the network error'),
    (error: HttpErrorResponse) => {
      expect(error.error.message).toEqual(emsg, 'message');
    }
  );

  const req = httpTestingController.expectOne(testUrl);

  // Create mock ErrorEvent, raised when something goes wrong at the network level.
  // Connection timeout, DNS error, offline, etc
  const mockError = new ErrorEvent('Network error', {
    message: emsg,
  });

  // Respond with mock error
  req.error(mockError);
});