home / skills / hoangnguyen0403 / agent-skills-standard / http-client

http-client skill

safe

This skill helps you implement HTTP client best practices with functional interceptors, typed responses, and service-based calls to improve reliability.

npx playbooks add skill hoangnguyen0403/agent-skills-standard --skill http-client

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

943 B

---
name: HTTP Client
description: Best practices for HttpClient, Interceptors, and API interactions.
metadata:
  labels: [angular, http, api, interceptors]
  triggers:
    files: ['**/*.service.ts', '**/*.interceptor.ts']
    keywords: [HttpClient, HttpInterceptorFn, withInterceptors]
---

# HTTP Client

## **Priority: P1 (HIGH)**

## Principles

- **Functional Interceptors**: Use `HttpInterceptorFn`. Class-based interceptors are deprecated.
- **Typed Responses**: Always type `http.get<User[]>()`.
- **Services**: Encapsulate all HTTP calls in Services. Never call `http` in Components.

## Guidelines

- **Caching**: Implement caching in interceptors or using `shareReplay(1)` in services.
- **Error Handling**: Catch errors in services or global interceptors, not components.
- **Context**: Use `HttpContext` to pass metadata to interceptors (e.g., specific caching rules).

## References

- [Interceptors](references/interceptors.md)

Overview

This skill documents practical best practices for using HTTP clients, with emphasis on functional interceptors, typed responses, and service-based API access. It focuses on patterns that improve safety, testability, and maintainability across TypeScript and multiple platform ecosystems. The guidance targets real-world concerns like caching, error handling, and passing metadata to interceptors.

How this skill works

It prescribes using functional interceptors (HttpInterceptorFn) to centralize cross-cutting HTTP behavior and avoid deprecated class-based interceptors. All HTTP calls are encapsulated inside dedicated services that return strongly typed responses. Caching, error transformation, and metadata-driven behavior are implemented in interceptors or service layers so components remain logic-free.

When to use it

When building API clients for frontend or mobile apps to ensure consistent handling of HTTP concerns.
When needing centralized caching, logging, auth token handling, or request/response transformation.
When migrating away from class-based interceptors to modern functional interceptor patterns.
When you want typed API contracts to flow through the app for safer refactors and better IDE support.
When you need to attach per-request metadata (e.g., cache rules) without polluting component code.

Best practices

Use HttpInterceptorFn-style interceptors to implement cross-cutting concerns (auth, retries, logging).
Never call the low-level http client directly from components; create services that expose typed methods.
Always type responses (e.g., http.get<User[]>()) to catch errors at compile time and aid documentation.
Implement caching in interceptors or via shareReplay(1) inside services to share results and reduce network load.
Handle errors centrally in services or a global interceptor, map or rethrow meaningful error shapes to callers.
Use HttpContext to pass per-request metadata (cache policies, skip-interceptor flags) to interceptors.

Example use cases

A user service exposing getUsers(): Observable<User[]> that caches results and retries transient failures.
An auth interceptor that injects tokens into headers and refreshes tokens on 401 responses using functional interceptors.
A logging interceptor that records request timings and outcome, triggered only for requests without a 'no-logging' context flag.
An image API service that applies aggressive cache rules for media endpoints while leaving other endpoints uncached.

FAQ

Why prefer functional interceptors over class-based ones?

Functional interceptors are the modern pattern: they are simpler, easier to compose and test, and replace deprecated class-based interceptors.

Where should I catch and transform HTTP errors?

Catch and transform errors in services or a global interceptor to keep components free of HTTP-specific logic and to provide consistent error shapes.