v0.2.1

What's in this release

A documentation release. No runtime changes — the only source edits are three TypeScript annotations that are erased at compile time, so the shipped JavaScript is unchanged from v0.2.0 and upgrading cannot alter behaviour.

The reason to read on is that the setup instructions in v0.2.0 were wrong in a way that silently disabled a feature.

Fixed: the documented interceptor order

v0.2.0's README recommended registering the interceptors like this:

withInterceptors([retryInterceptor, apiErrorInterceptor, apiSuccessInterceptor]);

If you copied that, retry has never run in your application. No error, no warning — every request simply gets one attempt.

The first interceptor in the array is the outermost one, so apiErrorInterceptor was nested inside retryInterceptor. By the time a failure reached the retry logic it had already been normalised from an HttpErrorResponse into a plain
ApiError, and retryInterceptor only retries HttpErrorResponses. Nothing ever matched.

The correct order — now documented — is:

withInterceptors([
  apiErrorInterceptor,    // outermost: sees the failure that survived every retry
  apiSuccessInterceptor,
  retryInterceptor,
  bearerTokenInterceptor, // innermost: re-signs every attempt
]);

Measured against a backend returning 503 with maxRetries: 2:

Order	HTTP attempts	Error handler calls
[retryInterceptor, apiErrorInterceptor]	1	1
[apiErrorInterceptor, retryInterceptor]	3	1

Putting your auth interceptor last matters too: inside the retry loop, each attempt is signed with a fresh token instead of replaying an expired one.

Action required: reorder your withInterceptors([...]) array. There is no code change to pick up — v0.2.0 behaves identically once the order is right.

New: documentation site

Full documentation now lives at https://ismailza.github.io/ngx-api-client/ — getting started, guides for each concern (versioning, error handling, retry, loading state, testing) and a reference for the public API.

Also

• Internal type annotations tightened; no public API or .d.ts change.
• READMEs gained badges and links to the documentation site.

Full Changelog: v0.2.0...v0.2.1

v0.2.0

ngx-api-client v0.2.0

Features

• make api versioning strategy and path prefix configurable (cd3aa42)

Version placement is now a strategy rather than a hardcoded /api/v{n} URL segment, and the static path prefix is configurable too.

provideApi({
  baseUrl: 'https://api.example.com',
  prefix: 'api', // '' or false to serve from the root
  version: 1, // number | string ('2024-01-01', 'beta')
  versioning: 'url', // 'query-param' | 'header' | 'media-type' | false
});

versioning	GET /orders
'url' (default)	/api/v1/orders
'query-param'	/api/orders?v=1
'header'	/api/orders + X-API-Version: 1
'media-type'	Accept: application/vnd.api.v1+json
false	/api/orders, no version sent

• each strategy's naming is overridable — parameterName, headerName, mediaType, and the URL version prefix
• version accepts a string for date- or label-based schemes; per-request version: false and prefix: false opt a single call out
• new API_PREFIX and API_VERSIONING tokens, plus the ApiVersioningStrategy, ApiVersioningConfig and API_VERSIONING_DEFAULTS exports

Notes

• No migration needed. Defaults are unchanged — requests still resolve to {baseUrl}/api/v1{endpoint} — and API_VERSION is still provided, now typed number | string.
• A header or query parameter set explicitly on a request is never overwritten by the versioning strategy, and a version placed in the URL is percent-encoded.
• With versioning: false there is no strategy to carry a version, so a per-request version is ignored.
• A trailing slash on baseUrl is trimmed rather than producing a double slash.
• Config options fall back to their defaults when passed explicitly as undefined, so assembling config from optional sources (prefix: environment.apiPrefix) is safe.

Full Changelog: v0.1.0...v0.2.0

v0.1.0

🎉 ngx-api-client v0.1.0

We're excited to announce the first public release of @ismailza/ngx-api-client!

ngx-api-client is a modern, strongly typed, and interceptor-driven HTTP client for Angular applications. It provides a robust foundation for consuming REST APIs with built-in support for API versioning, RFC 9457 Problem Details, retry policies, and a fully extensible request pipeline.

✨ Highlights

🚀 Core HTTP Client

• Strongly typed API client built on Angular's HttpClient
• Generic request and response handling
• Clean and extensible API surface

🔀 API Versioning

• Built-in API version support
• Automatic version injection into request URLs
• Centralized version management

🛡️ RFC 9457 Problem Details

• Automatic normalization of application/problem+json responses
• Consistent error model across your application
• Simplified server-side error handling

🔄 Retry with Exponential Backoff

• Configurable retry strategy
• Exponential backoff support
• Smart retry for transient failures

🧩 Interceptor-Driven Architecture

• Request interceptors
• Response interceptors
• Error interceptors
• Success handlers
• Fully pluggable processing pipeline

⚙️ Flexible Configuration

• Angular Dependency Injection integration
• Global client configuration
• Highly customizable behavior

📦 Developer Experience

• Full TypeScript support
• Tree-shakable architecture
• Standalone Angular compatible
• Lightweight with minimal setup

📚 Documentation

See the project README for installation instructions, configuration options, and usage examples.

❤️ Feedback

This is the initial public release of ngx-api-client. Feedback, bug reports, feature requests, and contributions are greatly appreciated as the project continues to evolve.

---

Full Changelog: https://github.com/ismailza/ngx-api-client/releases/tag/v0.1.0