儘管攔截器能夠修改請求和響應，但 HttpRequest 和 HttpResponse 例項屬性為 `readonly`，這意味著其具有 `immutability` 特性。

這種特性是 Angular 框架有意為之的設計：應用程式可能會在一個 HTTP 請求成功完成之前，多次重試請求。換言之，這意味著 Interceptor chain 可以多次重新處理(`re-process`)相同的請求。 如果攔截器可以修改原始請求物件，則重試操作將從修改後的請求開始，而不是從原始請求開始，這會給應用程式的處理引入極大的不確定性。

因此，Angular Interceptor 處理上下文中的 HTTP 請求和響應的 `immutability` 特性，確保攔截器在每次嘗試中處理的是相同的請求。

TypeScript 阻止開發人員設定 HttpRequest 物件中具有 `readonly` 的屬性，看個具體的例子：

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

如果應用程式裡必須更改 HTTP Request，請先克隆它並修改克隆，然後再將其傳遞給 next.handle()。 可以在一個步驟中克隆和修改請求，如以下示例所示：

```typescript
// 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);
```

下面是 SAP Spartacus Interceptor 中使用 clone 方法去修改一個 HTTP Request 的具體例子：

[圖片]

TypeScript 的 readonly 屬性，並不能阻止 Request body 欄位被 `deep update`.

下列程式碼能工作，然而卻是一個糟糕的設計，原因如前所述：如果該 Interceptor 被重複呼叫，則每次呼叫會在前一次呼叫修改的 HTTP Request 的基礎上再次進行修改，不斷造成 `Side Effect`:

```typescript
req.body.name = req.body.name.trim(); // bad idea!
```
Angular 推薦的做法依次是：

- 對 Request body 進行 copy，並修改 copy 版本
- 使用 HTTP Request 的 `clone` 方法，克隆請求物件。
- 用修改後的 body copy 版本，替換克隆出來的 HTTP 請求的 body 欄位。

虛擬碼如下：

```typescript
// 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);
```

關於 Angular HTTP Interceptor 中 Request 和 Response 的 immutable 特性

相關文章