How does an explicit source marker on a handler parameter differ from letting a framework infer the source?
answer
- a marker states it, inference guesses it
- name matches route variable; type picks body
- rename silently moves an inferred source
- wire name cannot always be an identifier
basics
~20 sAn explicit marker states the source and the wire name, so binding is fixed by the declaration. Inference derives it from the parameter's name and type — shorter, but it changes silently when a name, type or route template changes.
solid answer
~50 sInference is a set of conventions: a parameter whose name matches a route variable binds from the **path**, a scalar binds from the **query** (or from form fields, depending on the framework and the request), a structured type binds from the **body**, and a framework-owned type is injected from the request context. It is compact, and it works while the conventions hold. An **explicit marker** instead names the source and, usually, the exact wire name — which is the only way to bind a hyphenated header or a query key whose spelling differs from the identifier. The practical difference is failure mode: with a marker, changing a parameter name is a rename; with inference, it can silently move the value to a different source, or to none, and the handler then sees an absent or wrong value rather than an error.
go deeper
Know that a marker on the parameter names where the value comes from, and that without one the framework applies conventions based on the parameter's name and type.
State the inference rules in order and give a concrete case where a rename or a route change quietly moves a value from one source to another.
Argue the failure modes: silent absence rather than an error, names lost in a build step, and tests that call handlers directly and never exercise the binder at all.
Set the convention for a codebase and make it enforceable — which sources must be marked, what the lint or review rule is, and what the signature has to tell documentation and client tooling.
## Two ways to answer "where does this value come from?" When the framework prepares a handler call it must decide, for each parameter, which part of the request feeds it. There are two ways to supply that decision, and most frameworks support both. **An explicit marker** is a declaration attached to the parameter that names the source — path, query, header, cookie, form field, body — and usually a **wire name**, the spelling used on the wire when it differs from the identifier in code. **Inference** is the framework applying conventions when no marker is present. The rules vary, but the family is recognisable: 1. The parameter's name matches a variable in the matched route template, so bind it from the **path**. 2. The type is a scalar — text, number, boolean — so bind it from the **query string**, and in some frameworks from **form fields** when the request carries an encoded body. 3. The type is a structured object with no other rule claiming it, so parse the **body** into it. 4. The type is one the framework owns, so inject the corresponding **context** value instead of parsing anything. Where both are present, the marker wins: it is a statement, and inference is the fallback for parameters that make no statement. ## What each one costs | | Explicit marker | Inference | |---|---|---| | Where the contract lives | in the declaration | in the conventions plus the route | | Wire name differing from identifier | supported directly | usually impossible | | Renaming a parameter | a pure rename | may change or break the binding | | Adding a route variable | no effect | can capture an existing parameter | | Reading the handler cold | source is on the page | you must know the rules | | Verbosity | higher | lower | ## Why inference fails quietly The failures are worth enumerating, because none of them is loud: - **A rename moves the source.** Renaming a parameter that happened to match a route variable stops it matching, so it falls through to the next rule — typically the query string — and the handler starts reading a value the client controls freely instead of one the route captured. - **A route change captures a parameter.** Adding a variable to the template whose name collides with an existing parameter does the reverse: a value that used to come from the query now comes from the path. - **Names may not survive the build.** Name-based inference depends on parameter names being present at run time. Build steps that strip, minify or rewrite them turn a working convention into a binder that cannot match anything. - **A type change re-routes a value.** Widening a scalar into a structured type can move a parameter from the query string to the body under rule 3, changing the request shape without any change to the request-handling code. In each case the handler still compiles and still runs. The value is simply absent, or taken from somewhere else, and the symptom surfaces as a null, a zero, or a validation error far from the cause. ## When inference is the right call It is not a trap to be avoided on principle. Inference is good when the convention is strong and the surface is small: an internal service where every path variable is bound by a same-named parameter, a codebase with a lint rule that enforces the pairing, a team that reads the same handlers daily. The economics change with scale. Once many people edit the same handlers, once route templates are composed from prefixes declared elsewhere, or once wire names stop matching identifier rules, the marker's verbosity buys back more than it costs. A reasonable middle position that several teams land on: **mark every source that the client controls** — query, header, cookie, form, body — and let inference handle path variables and framework context, where a mismatch shows up immediately as a failure to route or to start. The point is not the exact line but that the line is chosen and enforced, rather than applied differently in every file. ## What the marker also buys A marker is read by more than the binder. Documentation generators, request-validation layers and client-generation tooling all read the same declaration, so an explicitly marked signature describes the endpoint's inputs without anyone maintaining a second description. An inferred signature describes them only to a reader who knows the framework's conventions — and the tooling has to reimplement those conventions to see what the endpoint accepts.
- Why does inference by parameter name sometimes stop working after a build step?Name-based rules need the parameter's name at run time. Toolchains that strip or rewrite names for size or obfuscation leave the binder with positional information only, so nothing matches the route variable or the query key. The usual fixes are a build setting that preserves names, or explicit markers that carry the wire name in the declaration itself.
- If a marker and inference would disagree, which one applies?The marker. Inference is the fallback for parameters that state nothing, so any explicit declaration overrides it. That is exactly why a marker is the cheapest fix for a value that started binding from the wrong place: it removes the parameter from the convention's reach without changing the handler's logic.
- How would you catch an inferred binding that has silently moved to another source?Test at the request level rather than by calling the handler directly — send a request that omits the value from the source you expect and assert the failure. A direct unit call passes arguments in by hand and never exercises the binder, so it cannot see where the value would have come from.
saying these in an interview costs you the question
- Thinking inference and an explicit marker always resolve to the same source
- Assuming a parameter name can express a hyphenated header or query key
- Believing a wrong inferred source shows up as a startup or compile error
- Renaming a handler parameter as if it were a purely local change
- Unit-testing handlers by direct calls and claiming binding is covered