关于 SAP Spartacus Angular HTTP In

Angular 按照开发人员提供的 HTTP Interceptors 的顺序来依次 调用这些拦截器。

例如，考虑这种例子，开发人员希望处理 HTTP 请求的身份验证，并在将它们发送到服务器之前记录它们。要完成这个场景，可以按顺序先提供 AuthInterceptor，然后再提供 LoggingInterceptor. Angular 应用发送出的请求，将从 AuthInterceptor 流向 LoggingInterceptor。相应的，这些请求的响应将反向流动，即从 LoggingInterceptor 返回到 AuthInterceptor.

以下是该过程的图形化表示：

流程中的最后一个拦截器始终是处理与服务器通信的 HttpBackend.

SAP Spartacus 开发中为令牌 HTTP_INTERCEPTORS 提供的绝大多数 Interceptor，都定义在 barrel 文件即 index.ts 内：

这些 Interceptor 彼此之间在业务上并没有依赖关系，所以没有严格的先后顺序定义要求。

大多数 HttpClient 方法返回 HttpResponse<any> 的 observables。 HttpResponse 类本身实际上是一个事件，其类型为 HttpEventType.Response. 但是，单个 HTTP 请求可以生成多个其他类型的事件，包括上传和下载进度事件。 HttpInterceptor.intercept() 和 HttpHandler.handle() 方法返回 HttpEvent<any> 的 observables.

下面是 SAP Spartacus 一个具体的 Interceptor 例子：

许多拦截器只关心传出请求并从 next.handle() 返回事件流而不修改它。 然而，一些拦截器需要检查和修改来自 next.handle() 的响应； 这些操作需要识别到流中的所有这些事件。

上图是 Spartacus Cart Checkout 场景使用 Interceptor 进行错误处理的一个例子。

首先从 rxjs/operators 里导入 Rxjs 执行错误处理的操作符 catchError：

当 HTTP 交互出现错误时，传入 catchError 操作符的箭头函数触发，如果触发时的实例变量 response 的类型为 HttpErrorResponse，那么继续判断当前的路由路径，是否包含了 checkout 片段：

这个判断通过下列函数执行：

  /**
   * Returns true if the parameter semantic route is part of "checkout"
   * Checkout semantic routes:
   * checkout
   * checkoutPaymentType
   * CheckoutShippingAddress
   * checkoutDeliveryMode
   * checkoutPaymentDetails
   * checkoutReviewOrder
   * checkoutLogin
   * @param semanticRoute
   */
  protected isUserInCheckoutRoute(semanticRoute?: string): boolean {
    return semanticRoute?.toLowerCase().startsWith('checkout') ?? false;
  }

如果上述函数返回 true，则通过 this.routingService.go, 重定向到 cart 页面：