c8e2fba13e
Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
47 lines
1.7 KiB
Markdown
47 lines
1.7 KiB
Markdown
# Handle API base URL, auth token, and errors via HTTP interceptors
|
|
|
|
- Status: accepted
|
|
- Date: 2026-04-26
|
|
|
|
## Context and Problem Statement
|
|
|
|
Every API call requires three cross-cutting concerns: prepending the API base URL, attaching the JWT bearer token, and unwrapping error responses into a consistent shape. How should these be applied across all HTTP calls without duplicating logic in each service?
|
|
|
|
## Considered Options
|
|
|
|
- Three chained HTTP interceptors
|
|
- Per-service base URL and token handling
|
|
- Single utility wrapper function
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Three chained HTTP interceptors", because they centralise cross-cutting concerns transparently and require no changes to individual services.
|
|
|
|
### Positive Consequences
|
|
|
|
- Services use relative paths (e.g. `/skydive/jumps`) — environment-agnostic.
|
|
- Auth header injection is transparent to all services.
|
|
- Uniform error payload shape across the entire application.
|
|
|
|
### Negative Consequences
|
|
|
|
- Services must always use relative paths starting with `/`. Passing an absolute URL would cause the base URL to be prepended twice.
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### Three chained HTTP interceptors
|
|
|
|
- Good, because zero duplication — logic defined once, applied everywhere.
|
|
- Good, because services remain unaware of environment or auth details.
|
|
- Bad, because interceptors apply globally — opting out requires explicit handling.
|
|
|
|
### Per-service base URL and token handling
|
|
|
|
- Good, because each service controls its own behaviour explicitly.
|
|
- Bad, because duplicates the same logic across every service.
|
|
|
|
### Single utility wrapper function
|
|
|
|
- Good, because more explicit than interceptors.
|
|
- Bad, because all service calls must go through the wrapper — easy to bypass accidentally.
|