使用 HTTP 与后端服务进行通信link

Communicating with backend services using HTTPlink

大多数前端应用都要通过 HTTP 协议与服务器通讯，才能下载或上传数据并访问其它后端服务。Angular 给应用提供了一个 HTTP 客户端 API，也就是 @angular/common/http 中的 HttpClient 服务类。

Most front-end applications need to communicate with a server over the HTTP protocol, in order to download or upload data and access other back-end services. Angular provides a client HTTP API for Angular applications, the HttpClient service class in @angular/common/http.

HTTP 客户端服务提供了以下主要功能。

The HTTP client service offers the following major features.

• 请求类型化响应对象的能力。

  The ability to request typed response objects.

• 简化的错误处理。

  Streamlined error handling.

• 各种特性的可测试性。

  Testability features.

• 请求和响应的拦截机制。

  Request and response interception.

先决条件link

Prerequisiteslink

在使用 HttpClientModule 之前，你应该对下列内容有基本的了解：

Before working with the HttpClientModule, you should have a basic understanding of the following:

• TypeScript 编程

  TypeScript programming

• HTTP 协议的用法

  Usage of the HTTP protocol

• Angular 的应用设计基础，就像Angular 基本概念中描述的那样

  Angular app-design fundamentals, as described in Angular Concepts

• Observable 相关技术和操作符。参阅可观察对象部分。

  Observable techniques and operators. See the Observables guide.

服务器通讯的准备工作link

Setup for server communicationlink

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

Before you can use 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 {}
    

然后，你可以把 HttpClient 服务注入成一个应用类的依赖项，如下面的 ConfigService 例子所示。

You can then inject the HttpClient service as a dependency of 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) { }
}
    

HttpClient 服务为所有工作都使用了可观察对象。你必须导入范例代码片段中出现的 RxJS 可观察对象和操作符。比如 ConfigService 中的这些导入就很典型。

The HttpClient service makes use of observables for all transactions. You must import the RxJS observable and operator symbols that appear in the example snippets. These ConfigService imports are typical.

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

从服务器请求数据link

Requesting data from a serverlink

使用 HttpClient.get()方法从服务器获取数据。该异步方法会发送一个 HTTP 请求，并返回一个 Observable，它会在收到响应时发出所请求到的数据。返回的类型取决于你调用时传入的 observe 和 responseType 参数。

Use the HttpClient.get()method to fetch data from a server. The asynchronous method sends an HTTP request, and returns an Observable that emits the requested data when the response is received. The return type varies based on the observe and responseType values that you pass to the call.

get() 方法有两个参数。要获取的端点 URL，以及一个可以用来配置请求的选项对象。

The get() method takes two arguments; the endpoint URL from which to fetch, and an options object that you can use to configure the request.

      
        content_copy
      
      options: {
    headers?: HttpHeaders | {[header: string]: string | string[]},
    observe?: 'body' | 'events' | 'response',
    params?: HttpParams|{[param: string]: string | number | boolean | ReadonlyArray<string | number | boolean>},
    reportProgress?: boolean,
    responseType?: 'arraybuffer'|'blob'|'json'|'text',
    withCredentials?: boolean,
  }
    

这些重要的选项包括 observe 和 responseType 属性。

Important options include the observe and responseType properties.

• observe 选项用于指定要返回的响应内容。

  The observe option specifies how much of the response to return.

• responseType 选项指定返回数据的格式。

  The responseType option specifies the format in which to return data.

应用经常会从服务器请求 JSON 数据。在 ConfigService 例子中，该应用需要服务器 config.json 上的一个配置文件来指定资源的 URL。

Applications often request JSON data from a server. In the ConfigService example, the app needs a configuration file on the server, config.json, that specifies resource URLs.

      
        content_copy
      
      {
  "heroesUrl": "api/heroes",
  "textfile": "assets/textfile.txt",
  "date": "2020-01-29"
}
    

要获取这类数据，get() 调用需要以下几个选项： {observe: 'body', responseType: 'json'}。这些是这些选项的默认值，所以下面的例子不会传递 options 对象。后面几节展示了一些额外的选项。

To fetch this kind of data, the get() call needs the following options: {observe: 'body', responseType: 'json'}. These are the default values for those options, so the following examples do not pass the options object. Later sections show some of the additional option possibilities.

这个例子符合通过定义一个可复用的可注入服务来执行数据处理功能来创建可伸缩解决方案的最佳实践。除了提取数据外，该服务还可以对数据进行后处理，添加错误处理，并添加重试逻辑。

The example conforms to the best practices for creating scalable solutions by defining a re-usable injectable service to perform the data-handling functionality. In addition to fetching data, the service can post-process the data, add error handling, and add retry logic.

ConfigService 使用 HttpClient.get() 方法获取这个文件。

The ConfigService fetches this file using the HttpClient.get() method.

      
        content_copy
      
      configUrl = 'assets/config.json';

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

ConfigComponent 注入了 ConfigService 并调用了 getConfig 服务方法。

The ConfigComponent injects the ConfigService and calls the getConfig service method.

由于该服务方法返回了一个 Observable 配置数据，该组件会订阅该方法的返回值。订阅回调只会对后处理进行最少量的处理。它会把数据字段复制到组件的 config 对象中，该对象在组件模板中是数据绑定的，用于显示。

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

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

请求输入一个类型的响应link

Requesting a typed responselink

你可以构造自己的 HttpClient 请求来声明响应对象的类型，以便让输出更容易、更明确。所指定的响应类型会在编译时充当类型断言。

You can structure your HttpClient request to declare the type of the response object, to make consuming the output easier and more obvious. Specifying the response type acts as a type assertion at compile time.

要指定响应对象类型，首先要定义一个具有必需属性的接口。这里要使用接口而不是类，因为响应对象是普通对象，无法自动转换成类的实例。

To specify the response object type, first define an interface with the required properties. Use an interface rather than a class, because the response is a plain object that cannot be automatically converted to an instance of a class.

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

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

Next, 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 });
}
    

要访问接口中定义的属性，必须将从 JSON 获得的普通对象显式转换为所需的响应类型。例如，以下 subscribe 回调会将 data 作为对象接收，然后进行类型转换以访问属性。

To access properties that are defined in an interface, you must explicitly convert the plain object you get from the JSON to the required response type. For example, the following subscribe callback receives data as an Object, and then type-casts it in order to access the properties.

      
        content_copy
      
      .subscribe(data => this.config = {
  heroesUrl: (data as any).heroesUrl,
  textfile:  (data as any).textfile,
});
    

      
        content_copy
      
      options: {
    ...
    observe?: 'body' | 'events' | 'response',
    ...
    responseType?: 'arraybuffer'|'blob'|'json'|'text',
    ...
  }
    

      
        content_copy
      
      // this works
client.get('/foo', {responseType: 'text'})

// but this does NOT work
const options = {
  responseType: 'text',
};
client.get('/foo', options)
    

      
        content_copy
      
      const options = {
  responseType: 'text' as const,
};
client.get('/foo', options);
    

读取完整的响应体link

Reading the full responselink

在前面的例子中，对 HttpClient.get() 的调用没有指定任何选项。默认情况下，它返回了响应体中包含的 JSON 数据。

In the previous example, the call to HttpClient.get() did not specify any options. By default, it returned the JSON data contained in the response body.

你可能还需要关于这次对话的更多信息。比如，有时候服务器会返回一个特殊的响应头或状态码，来指出某些在应用的工作流程中很重要的条件。

You might need more information about the transaction than is contained in the response body. Sometimes servers return special headers or status codes to indicate certain conditions that are important to the application workflow.

可以用 get() 方法的 observe 选项来告诉 HttpClient，你想要完整的响应对象：

Tell HttpClient that you want the full response with the observe option of the get() method:

      
        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 type HttpResponse rather than just the JSON data contained in the body.

该组件的 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.

发起 JSONP 请求link

Making a JSONP requestlink

当服务器不支持 CORS 协议时，应用程序可以使用 HttpClient 跨域发出 JSONP 请求。

Apps can use the HttpClient to make JSONP requests across domains when a server doesn't support CORS protocol.

Angular 的 JSONP 请求会返回一个 Observable。 遵循订阅可观察对象变量的模式，并在使用 async 管道管理结果之前，使用 RxJS map 操作符转换响应。

Angular JSONP requests return an Observable. Follow the pattern for subscribing to observables and use the RxJS map operator to transform the response before using the async pipe to manage the results.

在 Angular 中，通过在 NgModule 的 imports 中包含 HttpClientJsonpModule 来使用 JSONP。在以下范例中，searchHeroes() 方法使用 JSONP 请求来查询名称包含搜索词的英雄。

In Angular, use JSONP by including HttpClientJsonpModule in the NgModule imports. In the following example, the searchHeroes() method uses a JSONP request to query for heroes whose names contain the search term.

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

  const heroesURL = `${this.heroesURL}?${term}`;
  return this.http.jsonp(heroesUrl, 'callback').pipe(
      catchError(this.handleError('searchHeroes', [])) // then handle the error
    );
}
    

该请求将 heroesURL 作为第一个参数，并将回调函数名称作为第二个参数。响应被包装在回调函数中，该函数接受 JSONP 方法返回的可观察对象，并将它们通过管道传给错误处理程序。

This request passes the heroesURL as the first parameter and the callback function name as the second parameter. The response is wrapped in the callback function, which takes the observables returned by the JSONP method and pipes them through to the error handler.

请求非 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 操作符（如“窃听”中所述）使代码可以检查通过可观察对象的成功值和错误值，而不会干扰它们。

The RxJS tap operator (as in "wiretap") lets the code inspect both success 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

Handling request errorslink

如果请求在服务器上失败了，那么 HttpClient 就会返回一个错误对象而不是一个成功的响应对象。

If the request fails on the server, HttpClient returns an error object instead of a successful response.

执行服务器请求的同一个服务中也应该执行错误检查、解释和解析。

The same service that performs your server transactions should also perform error inspection, interpretation, and resolution.

发生错误时，你可以获取失败的详细信息，以便通知你的用户。在某些情况下，你也可以自动重试该请求。

When an error occurs, you can obtain details of what failed in order to inform your user. In some cases, you might also automatically retry the request.

获取错误详情link

Getting error detailslink

当数据访问失败时，应用会给用户提供有用的反馈。原始的错误对象作为反馈并不是特别有用。除了检测到错误已经发生之外，还需要获取错误详细信息并使用这些细节来撰写用户友好的响应。

An app should give the user useful feedback when data access fails. A raw error object is not particularly useful as feedback. In addition to detecting that an error has occurred, you need to get error details and use those details to compose a user-friendly response.

可能会出现两种类型的错误。

Two types of errors can occur.

• 服务器端可能会拒绝该请求，并返回状态码为 404 或 500 的 HTTP 响应对象。这些是错误响应。

  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 操作符也会抛出异常。这些错误会产生 JavaScript 的 ErrorEvent 对象。 这些错误的 status 为 0，并且其 error 属性包含一个 ProgressEvent 对象，此对象的 type 属性可以提供更详细的信息。

  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 have status set to 0 and the error property contains a ProgressEvent object, whose type might provide further information.

HttpClient 在其 HttpErrorResponse 中会捕获两种错误。你可以检查一下这个响应是否存在错误。

HttpClient captures both kinds of errors in its HttpErrorResponse. You can inspect that response to identify the error's cause.

下面的例子在之前定义的 ConfigService 中定义了一个错误处理程序。

The following example defines an error handler in the previously defined ConfigService.

      
        content_copy
      
      private handleError(error: HttpErrorResponse) {
  if (error.status === 0) {
    // A client-side or network error occurred. Handle it accordingly.
    console.error('An error occurred:', error.error);
  } 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。下列代码修改了 getConfig() 方法，它使用一个管道把 HttpClient.get() 调用返回的所有 Observable 发送给错误处理器。

The handler returns an RxJS ErrorObservable with a user-friendly error message. The following code updates the getConfig() method, using a pipe to send all observables returned by the HttpClient.get() call to the error handler.

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

重试失败的请求link

Retrying a failed requestlink

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

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

RxJS 库提供了几个重试操作符。例如，retry() 操作符会自动重新订阅一个失败的 Observable 几次。重新订阅 HttpClient 方法会导致它重新发出 HTTP 请求。

The RxJS library offers several retry operators. For example, the retry() operator 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.

下面的例子演示了如何在把一个失败的请求传给错误处理程序之前，先通过管道传给 retry() 操作符。

The following example shows how you can pipe a failed request to the retry() operator before passing it to 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
    );
}
    

把数据发送到服务器link

Sending data to a serverlink

除了从服务器获取数据外，HttpClient 还支持其它一些 HTTP 方法，比如 PUT，POST 和 DELETE，你可以用它们来修改远程数据。

In addition to fetching data from a server, HttpClient supports other HTTP methods such as PUT, POST, and DELETE, which you can use to modify the remote data.

本指南中的这个范例应用包括一个简略版本的《英雄之旅》，它会获取英雄数据，并允许用户添加、删除和修改它们。 下面几节在 HeroesService 范例中展示了数据更新方法的一些例子。

The sample app for this guide includes an abridged version of the "Tour of Heroes" example that fetches heroes and enables users to add, delete, and update them. The following sections show examples of the data-update methods from the sample's HeroesService.

发起一个 POST 请求link

Making a POST requestlink

应用经常在提交表单时通过 POST 请求向服务器发送数据。 下面这个例子中，HeroesService 在向数据库添加英雄时发起了一个 HTTP POST 请求。

Apps often send data to a server with a POST request when submitting a form. In the following example, the HeroesService makes an HTTP POST request 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, which you can use to specify that you expect the server to return data of a given type. The method takes a resource URL and two additional parameters:

• body - 要在请求体中 POST 过去的数据。

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

• options - 一个包含方法选项的对象，在这里，它用来指定必要的请求头。

  options - An object containing method options which, in this case, specify required headers.

这个例子捕获了前面所讲的错误。

The example catches errors as 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 这样的操作符来在实际执行 HTTP 请求之前，先对这个可观察对象进行扩展。

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

应用可以使用 HttpClient 服务发送 PUT 请求。下面的 HeroesService 范例（就像 POST 范例一样）用一个修改过的数据替换了该资源。

An app can send PUT requests using the HTTP client service. The following HeroesService example, like the POST example, replaces a resource with updated data.

      
        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))
    );
}
    

对于所有返回可观察对象的 HTTP 方法，调用者（HeroesComponent.update()）必须 subscribe()从 HttpClient.put() 返回的可观察对象，才会真的发起请求。

As for any of the HTTP methods that return an observable, the caller, HeroesComponent.update() must subscribe()to the observable returned from the HttpClient.put() in order to initiate the request.

添加和更新请求头link

Adding and updating headerslink

很多服务器都需要额外的头来执行保存操作。 例如，服务器可能需要一个授权令牌，或者需要 Content-Type 头来显式声明请求体的 MIME 类型。

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

添加请求头link

Adding headerslink

HeroesService 在一个 httpOptions 对象中定义了这样的头，它们被传给每个 HttpClient 的保存型方法。

The HeroesService defines such headers in an httpOptions object that are 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'
  })
};
    

更新请求头link

Updating headerslink

你不能直接修改前面的选项对象中的 HttpHeaders 请求头，因为 HttpHeaders 类的实例是不可变对象。请改用 set() 方法，以返回当前实例应用了新更改之后的副本。

You can't directly modify the existing headers within the previous options object because instances of the HttpHeaders class are immutable. Use the set() method instead, to return a clone of the current instance with the new changes applied.

下面的例子演示了当旧令牌过期时，可以在发起下一个请求之前更新授权头。

The following example shows how, when an old token has expired, you can update the authorization header before making the next request.

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

配置 HTTP URL 参数link

Configuring HTTP URL parameterslink

使用 HttpParams 类和 params 选项在你的 HttpRequest 中添加 URL 查询字符串。

Use the HttpParams class with the params request option to add URL query strings in your HttpRequest.

下面的例子中，searchHeroes() 方法用于查询名字中包含搜索词的英雄。

The following example, the searchHeroes() method queries for heroes whose names contain the search term.

首先导入 HttpParams 类。

Start by importing HttpParams class.

      
      import {HttpParams} from "@angular/common/http";
    

      
        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 编码的搜索参数来构造一个 options 对象。例如，如果搜索词是 "cat"，那么 GET 请求的 URL 就是 api/heroes?name=cat。

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

HttpParams 是不可变对象。如果需要更新选项，请保留 .set() 方法的返回值。

The HttpParams object is immutable. If you need to update the options, save the returned value of the .set() method.

你也可以使用 fromString 变量从查询字符串中直接创建 HTTP 参数：

You can also create HTTP parameters directly from a query string by using the fromString variable:

      
      const params = new HttpParams({fromString: 'name=foo'});
    

拦截请求和响应link

Intercepting requests and responseslink

借助拦截机制，你可以声明一些拦截器，它们可以检查并转换从应用中发给服务器的 HTTP 请求。这些拦截器还可以在返回应用的途中检查和转换来自服务器的响应。多个拦截器构成了请求/响应处理器的双向链表。

With interception, you declare interceptors that inspect and transform HTTP requests from your application to a server. The same interceptors can also inspect and transform a 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.

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

      
        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);
  }
}
    

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

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 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 会按你提供拦截器的顺序应用它们。例如，考虑一个场景：你想处理 HTTP 请求的身份验证并记录它们，然后再将它们发送到服务器。要完成此任务，你可以提供 AuthInterceptor 服务，然后提供 LoggingInterceptor 服务。发出的请求将从 AuthInterceptor 到 LoggingInterceptor。这些请求的响应则沿相反的方向流动，从 LoggingInterceptor 回到 AuthInterceptor。以下是该过程的直观表示：

Angular applies interceptors in the order that you provide them. For example, consider a situation in which you want to handle the authentication of your HTTP requests and log them before sending them to a server. To accomplish this task, you could provide an AuthInterceptor service and then a LoggingInterceptor service. Outgoing requests would flow from the AuthInterceptor to the AuthInterceptor. Responses from these requests would flow in the other direction, from LoggingInterceptor back to AuthInterceptor. The following is a visual representation of the process:

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

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.

处理拦截器事件link

Handling interceptor eventslink

大多数 HttpClient 方法都会返回 HttpResponse<any> 型的可观察对象。HttpResponse 类本身就是一个事件，它的类型是 HttpEventType.Response。但是，单个 HTTP 请求可以生成其它类型的多个事件，包括报告上传和下载进度的事件。HttpInterceptor.intercept() 和 HttpHandler.handle() 会返回 HttpEvent<any> 型的可观察对象。

Most HttpClient methods return observables of HttpResponse<any>. The HttpResponse class itself is actually an event, whose type is HttpEventType.Response. A single HTTP request can, however, generate multiple events of other types, including upload and download progress events. The methods HttpInterceptor.intercept() and HttpHandler.handle() return observables of HttpEvent<any>.

很多拦截器只关心发出的请求，而对 next.handle() 返回的事件流不会做任何修改。 但是，有些拦截器需要检查并修改 next.handle() 的响应。上述做法就可以在流中看到所有这些事件。

Many interceptors are only concerned with the outgoing request and return the event stream from next.handle() without modifying it. Some interceptors, however, need to examine and modify the response from next.handle(); these operations can see all of these events in the stream.

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

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

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

They are immutable for a good reason: an app might retry a request several times before it succeeds, which means that the interceptor chain can 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.

TypeScript 会阻止你设置 HttpRequest 的只读属性。

TypeScript prevents you from setting HttpRequest read-only properties.

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

如果你必须修改一个请求，先把它克隆一份，修改这个克隆体后再把它传给 next.handle()。你可以在一步中克隆并修改此请求，例子如下。

If you must alter a 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 shown in the following 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

Modifying a 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!
    

如果必须修改请求体，请执行以下步骤。

If you must modify the request body, follow these steps.

1. 复制请求体并在副本中进行修改。

   Copy the body and make your change in the copy.

2. 使用 clone() 方法克隆这个请求对象。

   Clone the request object, using its clone() method.

3. 用修改过的副本替换被克隆的请求体。

   Replace the clone's body with the modified copy.

      
        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 body in a clonelink

有时，你需要清除请求体而不是替换它。为此，请将克隆后的请求体设置为 null。

Sometimes you need to clear the request body rather than replace it. To do this, set the cloned request body to null.

      
        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
    

HTTP 拦截器用例link

Http interceptor use-caseslink

以下是拦截器的一些常见用法。

Below are a number of common uses for interceptors.

设置默认请求头link

Setting 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

Logging request and response pairslink

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

Because interceptors can process the request and response together, they can perform tasks such as timing and logging 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 succeeded 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.

自定义 JSON 解析link

Custom JSON parsinglink

拦截器可用来以自定义实现替换内置的 JSON 解析。

Interceptors can be used to replace the built-in JSON parsing with a custom implementation.

以下示例中的 CustomJsonInterceptor 演示了如何实现此目的。如果截获的请求期望一个 'json' 响应，则将 responseType 更改为 'text' 以禁用内置的 JSON 解析。然后，通过注入的 JsonParser 解析响应。

The CustomJsonInterceptor in the following example demonstrates how to achieve this. If the intercepted request expects a 'json' response, the responseType is changed to 'text' to disable the built-in JSON parsing. Then the response is parsed via the injected JsonParser.

      
        content_copy
      
      // The JsonParser class acts as a base class for custom parsers and as the DI token.
@Injectable()
export abstract class JsonParser {
  abstract parse(text: string): any;
}

@Injectable()
export class CustomJsonInterceptor implements HttpInterceptor {
  constructor(private jsonParser: JsonParser) {}

  intercept(httpRequest: HttpRequest<any>, next: HttpHandler) {
    if (httpRequest.responseType === 'json') {
      // If the expected response type is JSON then handle it here.
      return this.handleJsonResponse(httpRequest, next);
    } else {
      return next.handle(httpRequest);
    }
  }

  private handleJsonResponse(httpRequest: HttpRequest<any>, next: HttpHandler) {
    // Override the responseType to disable the default JSON parsing.
    httpRequest = httpRequest.clone({responseType: 'text'});
    // Handle the response using the custom parser.
    return next.handle(httpRequest).pipe(map(event => this.parseJsonResponse(event)));
  }

  private parseJsonResponse(event: HttpEvent<any>) {
    if (event instanceof HttpResponse && typeof event.body === 'string') {
      return event.clone({body: this.jsonParser.parse(event.body)});
    } else {
      return event;
    }
  }
}
    

然后，你可以实现自己的自定义 JsonParser。这是一个具有特殊日期接收器的自定义 JsonParser。

You can then implement your own custom JsonParser. Here is a custom JsonParser that has a special date reviver.

      
        content_copy
      
      @Injectable()
export class CustomJsonParser implements JsonParser {
  parse(text: string): any {
    return JSON.parse(text, dateReviver);
  }
}

function dateReviver(key: string, value: any) {
/* . . . */
}
    

你提供 CustomParser 以及 CustomJsonInterceptor。

You provide the CustomParser along with the CustomJsonInterceptor.

      
        content_copy
      
      { provide: HTTP_INTERCEPTORS, useClass: CustomJsonInterceptor, multi: true },
{ provide: JsonParser, useClass: CustomJsonParser },
    

用拦截器实现缓存link

Caching requestslink

拦截器还可以自行处理这些请求，而不用转发给 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 in the following example demonstrates this approach.

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

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

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

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

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

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

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

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

  If a cacheable 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()。这个函数会创建一个没有请求头的请求克隆体，这是因为 npm API 禁止它们。然后，该函数把请求的克隆体转发给 next.handle()，它会最终调用服务器并返回来自服务器的响应对象。

  If a cacheable request is not in cache, the code calls sendRequest(). This function creates a request clone without headers, because the npm API forbids them. The function then forwards the clone of the request to next.handle() which ultimately calls the server and returns the server's response.

      
        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() 是如何在返回应用程序的过程中拦截响应的。该方法通过 tap() 操作符来管理响应对象，该操作符的回调函数会把该响应对象添加到缓存中。

Note how sendRequest() intercepts the response on its way back to the application. This method 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

Using interceptors to request multiple valueslink

HttpClient.get() 方法通常会返回一个可观察对象，它会发出一个值（数据或错误）。拦截器可以把它改成一个可以发出多个值的可观察对象。

The HttpClient.get() method normally returns an observable that emits a single value, either the data or an error. An interceptor can change this to an observable that emits multiple values.

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

The following revised version of the CachingInterceptor optionally returns an observable that immediately emits the cached response, sends the request on to the npm web API, 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);
    

修改后的 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 makes the request when subscribed.

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

  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

Tracking and showing request progresslink

应用程序有时会传输大量数据，而这些传输可能要花很长时间。文件上传就是典型的例子。你可以通过提供关于此类传输的进度反馈，为用户提供更好的体验。

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

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

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}.`;
  }
}
    

通过防抖来优化与服务器的交互link

Optimizing server interaction with debouncinglink

如果你需要发一个 HTTP 请求来响应用户的输入，那么每次按键就发送一个请求的效率显然不高。最好等用户停止输入后再发送请求。这种技术叫做防抖。

If you need to make an HTTP request in response to user input, it's not efficient to send a request for every keystroke. It's better to wait until the user stops typing and then send a request. This technique is known as debouncing.

考虑下面这个模板，它让用户输入一个搜索词来按名字查找 npm 包。 当用户在搜索框中输入名字时，PackageSearchComponent 就会把这个根据名字搜索包的请求发给 npm web API。

Consider the following template, which lets a user enter a search term to find an npm package by name. 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.

      
        content_copy
      
      <input type="text" (keyup)="search(getValue($event.target))" 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() 方法。

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

      
        content_copy
      
      getValue(target: EventTarget): string {
  return (target as HTMLInputElement).value;
}
    

这里，keyup 事件绑定会把每次按键都发送给组件的 search() 方法。下面的代码片段使用 RxJS 的操作符为这个输入实现了防抖。

The following snippet implements debouncing for this input using RxJS operators.

      
        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 emit 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, so that a search value reaches the service only if it's a new value and the user has stopped typing.

• debounceTime(500)⁠—等待用户停止输入（本例中为 1/2 秒）。

  debounceTime(500)⁠—Wait for the user to stop typing (1/2 second in this case).

• distinctUntilChanged()⁠—等待搜索文本发生变化。

  distinctUntilChanged()⁠—Wait until the search text changes.

• 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.

使用 switchMap() 操作符link

Using the switchMap() operatorlink

switchMap() 操作符接受一个返回 Observable 的函数型参数。在这个例子中，PackageSearchService.search 像其它数据服务方法那样返回一个 Observable。如果先前的搜索请求仍在进行中 （如网络连接不良），它将取消该请求并发送新的请求。

The switchMap() operator takes a function argument that returns an Observable. In the example, PackageSearchService.search returns an Observable, as other data service methods do. If a previous search request is still in-flight (as when the network connection is poor), the operator cancels that request and sends a new one.

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

Note that switchMap() returns service responses in their original request order, even if the server returns them out of order.

安全：XSRF 防护link

Security: XSRF protectionlink

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

Cross-Site Request Forgery (XSRF or CSRF) 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 等）把这个请求头发送给使用相对 URL 的请求。但不会在 GET/HEAD 请求中发送，也不会发送给使用绝对 URL 的请求。

By default, an interceptor sends this header on all mutating requests (such as POST) 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/testing 库能让这种 Mock 工作变得直截了当。

As for any external dependency, you must mock the HTTP backend so your tests can simulate interaction with a remote server. The @angular/common/http/testing library makes it straightforward to set up such mocking.

Angular 的 HTTP 测试库是专为其中的测试模式而设计的。在这种模式下，会首先在应用中执行代码并发起请求。 然后，这个测试会期待发起或未发起过某个请求，并针对这些请求进行断言， 最终对每个所预期的请求进行刷新（flush）来对这些请求提供响应。

Angular's HTTP testing library is designed for a pattern of testing in which the app executes code and makes requests first. The test then expects that certain requests have or have not been made, performs assertions against those requests, and finally provides responses by "flushing" each expected request.

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

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

搭建测试环境link

Setup for testinglink

要开始测试那些通过 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.inject(HttpClient);
    httpTestingController = TestBed.inject(HttpTestingController);
  });
  /// Tests begin ///
});
    

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

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

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

This setup also calls TestBed.inject() 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(
  request => request.headers.has('Authorization')
);
    

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

As with the previous expectOne(), the test fails 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);
});
    

将元数据传递给拦截器link

Passing metadata to interceptorslink

许多拦截器都需要进行配置或从配置中受益。考虑一个重试失败请求的拦截器。默认情况下，拦截器可能会重试请求三次，但是对于特别容易出错或敏感的请求，你可能要改写这个重试次数。

Many interceptors require or benefit from configuration. Consider an interceptor that retries failed requests. By default, the interceptor might retry a request three times, but you might want to override this retry count for particularly error-prone or sensitive requests.

HttpClient 请求包含一个上下文，该上下文可以携带有关请求的元数据。该上下文可供拦截器读取或修改，尽管发送请求时它并不会传输到后端服务器。这允许应用程序或其他拦截器使用配置参数来标记这些请求，例如重试请求的次数。

HttpClient requests contain a context that can carry metadata about the request. This context is available for interceptors to read or modify, though it is not transmitted to the backend server when the request is sent. This allows applications or other interceptors to tag requests with configuration parameters, such as how many times to retry a request.

创建上下文令牌link

Creating a context tokenlink

HttpContextToken 用于在上下文中存储和检索值。你可以用 new 运算符创建上下文令牌，如以下例所示：

Angular stores and retrieves a value in the context using an HttpContextToken. You can create a context token using the new operator, as in the following example:

      
        content_copy
      
      export const RETRY_COUNT = new HttpContextToken(() => 3);
    

HttpContextToken 创建期间传递的 lambda 函数 () => 3 有两个用途：

The lambda function () => 3 passed during the creation of the HttpContextToken serves two purposes:

1. 它允许 TypeScript 推断此令牌的类型： HttpContextToken<number>。这个请求上下文是类型安全的 —— 从请求上下文中读取令牌将返回适当类型的值。

   It allows TypeScript to infer the type of this token: HttpContextToken<number>. The request context is type-safe—reading a token from a request's context returns a value of the appropriate type.

2. 它会设置令牌的默认值。如果尚未为此令牌设置其他值，那么这就是请求上下文返回的值。使用默认值可以避免检查是否已设置了特定值。

   It sets the default value for the token. This is the value that the request context returns if no other value has been set for this token. Using a default value avoids the need to check if a particular value is set.

在发起请求时设置上下文值link

Setting context values when making a requestlink

发出请求时，你可以提供一个 HttpContext 实例，在该实例中你已经设置了一些上下文值。

When making a request, you can provide an HttpContext instance, in which you have already set the context values.

      
        content_copy
      
      this.httpClient
    .get('/data/feed', {
      context: new HttpContext().set(RETRY_COUNT, 5),
    })
    .subscribe(results => {/* ... */});
    

在拦截器中读取上下文值link

Reading context values in an interceptorlink

HttpContext.get() 在给定请求的上下文中读取令牌的值。如果尚未显式设置令牌的值，则 Angular 将返回令牌中指定的默认值。

Within an interceptor, you can read the value of a token in a given request's context with HttpContext.get(). If you have not explicitly set a value for the token, Angular returns the default value specified in the token.

      
        content_copy
      
      import {retry} from 'rxjs';

export class RetryInterceptor implements HttpInterceptor {
  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const retryCount = req.context.get(RETRY_COUNT);

    return next.handle(req).pipe(
        // Retry the request a configurable number of times.
        retry(retryCount),
    );
  }
}
    

上下文是可变的（Mutable）link

Contexts are mutablelink

与 HttpRequest 实例的大多数其他方面不同，请求上下文是可变的，并且在请求的其他不可变转换过程中仍然存在。这允许拦截器通过此上下文协调来操作。例如，RetryInterceptor 示例可以使用第二个上下文令牌来跟踪在执行给定请求期间发生过多少错误：

Unlike most other aspects of HttpRequest instances, the request context is mutable and persists across other immutable transformations of the request. This allows interceptors to coordinate operations through the context. For instance, the RetryInterceptor example could use a second context token to track how many errors occur during the execution of a given request:

      
        content_copy
      
      import {retry, tap} from 'rxjs/operators';
export const RETRY_COUNT = new HttpContextToken(() => 3);
export const ERROR_COUNT = new HttpContextToken(() => 0);

export class RetryInterceptor implements HttpInterceptor {
  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const retryCount = req.context.get(RETRY_COUNT);

    return next.handle(req).pipe(
        tap(null,
            () => {
              // An error has occurred, so increment this request's ERROR_COUNT.
              req.set(ERROR_COUNT, req.get(ERROR_COUNT) + 1);
            }),
        // Retry the request a configurable number of times.
        retry(retryCount),
    );
  }
}