Requests & Typed Responses

## What `http.get()` actually returns Angular's `HttpClient` is the injectable service in `@angular/common/http` that performs HTTP calls. Every request method — `get`, `post`, `put`, `patch`, `delete`, `head`, `options` and the generic `request` — returns an RxJS **`Observable`**. It is a **cold** Observable: it holds the recipe for a request (method, URL, body, headers, params, response type) but starts no network activity when it is created. Angular's own guide describes these Observables as *blueprints* for requests. That is why this service method is fine even though nothing seems to happen inside it: ```ts getForecast(city: string): Observable<Forecast> { return this.http.get<Forecast>('/api/forecast', { params: { city } }); } ``` The caller decides when and how often the request runs. ## Subscription is the send button When something subscribes, `HttpClient` runs the request pipeline. In the v22 source the request is wrapped as `of(req).pipe(concatMap((req) => this.handler.handle(req)))`, so the whole handler chain lives *inside* the subscription: 1. The subscriber attaches (an explicit `subscribe()`, the `async` pipe, `toSignal()`, or an operator such as `switchMap` subscribing on your behalf). 2. The interceptor chain runs for this subscription, then the backend receives the final `HttpRequest`. 3. The backend sends the request — `FetchBackend` by default since Angular 22, `HttpXhrBackend` when the app opts in with `withXhr()`. 4. When the full response arrives, the default `observe: 'body'` stream emits the body **once** and **completes**. A non-2xx status goes to the error channel instead. Nothing in steps 2-4 happens without step 1. The classic bug is a fire-and-forget write: ```ts saveFavourite(city: string): void { this.http.post('/api/favourites', { city }); // never subscribed: no POST is sent } ``` ## One subscription, one request Because the pipeline runs per subscription, the Observable is not a cached result: | What the code does | Requests on the wire | |---|---| | Builds `forecast$` and never subscribes | 0 | | Subscribes once (or one `async` pipe) | 1 | | Two `async` pipes on the same `forecast$` in one template | 2 | | `subscribe()` in the component plus an `async` pipe on the same Observable | 2 | | `retry(2)` after a failure | up to 3, each through the interceptor chain again | In code, the difference is easy to see: ```ts const forecast$ = this.weather.getForecast('Oslo'); forecast$.subscribe((f) => this.render(f)); // GET #1 forecast$.subscribe((f) => this.log(f.tempC)); // GET #2, same URL, separate call ``` This surprises people who expect Promise-like behaviour, where the work starts once and every `then` shares the result. With `HttpClient`, sharing one response between subscribers is an explicit choice — for example with RxJS's multicasting operators — and it belongs to the RxJS and request-deduplication topics rather than to `HttpClient` itself. ## Unsubscribing cancels the request The teardown function of the backend's Observable cancels in-flight work: - **`FetchBackend`** (the Angular 22 default) creates an `AbortController` per request and calls `abort()` on it if the subscription ends before the response is done. - **`HttpXhrBackend`** removes its listeners and calls `xhr.abort()` when the request is not yet `DONE`. - A cancelled request **does not emit an error** to the subscriber that left; the subscriber is simply gone. This is why `switchMap` over `HttpClient` gives real cancellation, and why the `async` pipe aborts a pending request when its view is destroyed. One caveat interviewers like: aborting stops the *browser* from waiting. If the request already reached the server, the server may still apply it. Cancelling a non-idempotent POST does not undo it. ## Completion and cleanup After delivering its response, an `HttpClient` Observable normally completes, so a forgotten subscription usually does not leak for long. Interceptors can change that (for example one that emits a cached value and then a fresh one), and a subscription that outlives its component can still run callbacks against destroyed state. The rules for tearing subscriptions down belong to the RxJS-interop topics; the point here is that completion is *usual*, not guaranteed. ## Mistakes to avoid - Expecting `http.get()` or `http.post()` to fire on its own. - Subscribing in a service and returning nothing, so callers cannot cancel or compose. - Binding the same Observable to two `async` pipes and wondering why the network panel shows two calls. - Treating an unsubscribe as a server-side rollback. - Calling a service method from a template, as in `{{ weather.getForecast(city) | async }}`. Every time the view is checked, the method returns a *new* Observable; the `async` pipe drops its old subscription (aborting that request) and subscribes to the new one, and because each arriving value marks the view for another check, the requests can repeat indefinitely. Create the Observable once, in a field or from a signal, and bind that.