Checkpoint: Where Does an Axios Decision Belong?

Axios becomes easier to reason about once its request contract, configuration scopes, normalized headers, and lifecycle are treated as one connected system. This checkpoint uses those established ideas to make a practical judgment: classify a client decision as contract, scope, lifecycle, or transport policy before changing a setting. That classification prevents two common mistakes—putting a destination rule in a global default and assuming a shared Axios API guarantees identical runtime capabilities.

Consider a dashboard that calls a company API from a browser, then calls the same API from a server-side job. The application wants a stable base URL, an authorization token, paginated queries, JSON responses, and a way to abort work when a user leaves the page. Later, the dashboard may also download a large export. All of those operations can use Axios, but they do not all belong at the same layer or carry the same runtime assumptions.

Four kinds of decisions in one request

Contract policy describes what the application means

A contract decision defines the meaning the application expects to preserve. The dashboard may treat a successful call as a response whose data contains users and a page marker. It may expect a request body to represent an update, query parameters to represent filters, and cancellation to mean that the result is no longer needed. These meanings sit above a particular socket API.

Axios supports this contract with a common request shape, response shape, Promise behavior, status validation, transformations, and error classification. The contract does not require the application to use the exact same transport everywhere. It requires each chosen transport to produce behavior that the application can interpret consistently enough for the use case.

This distinction helps with a subtle failure. If an API returns a 404 and the application wants to display an empty state, that is a status-policy decision. Changing the adapter does not solve it. The caller may change validateStatus or handle a rejected response with its attached status and data. The remote status is evidence; Axios’s resolution rule is the policy that turns that evidence into Promise control flow.

Scope policy describes how far a rule travels

The dashboard’s company API base URL and authorization policy belong on a client instance because they are shared by a coherent destination. The current page number belongs to one request. A timeout may belong to the instance if every API call needs a common ceiling, or to one request if an export is known to take longer. A response type of stream belongs to the export request rather than to every JSON operation.

This is not just tidy organization. Scope determines which future requests inherit the rule. A global authorization header can reach every host contacted through the global client. An instance narrows the intended relationship, but it still does not validate every URL passed to it. A request-level override makes an exception visible at the point where its reason is easiest to inspect.

The body illustrates the same rule.