Skip to content
tezvyn:

How would you implement a dependency requiring multi-source parameters?

Source: fastapi.tiangolo.comHardHow cards are made

How would you implement a dependency requiring multi-source parameters?

Tests if you know FastAPI resolves dependency params like endpoint params. Great answers annotate each parameter with its source inside the dependency so FastAPI injects them independently. Red flag: manually parsing Request or merging values in the endpoint.

What's really being asked

This question probes whether you understand that FastAPI's dependency injection system uses the same parameter resolution machinery for dependencies as it does for path operation functions. The interviewer wants to know if you recognize that a dependency callable is not a black box that receives a raw Request, but rather a function whose signature is introspected by FastAPI to map each parameter to the correct part of the HTTP request.

The full answer

First, explain that you write a normal Python function where each parameter is annotated with its source, such as Path for route variables, Header for headers, Query for query strings, or Cookie for cookies. Second, state that FastAPI inspects this signature automatically and resolves every parameter independently, exactly as it would for an endpoint function. Third, note that you then declare this function as a dependency using Depends in the path operation or in another dependency, creating a sub-dependency chain if needed. Fourth, mention that because resolution is annotation-driven, you can mix sources freely in a single dependency without touching the Request object directly.

The mistakes people make

A major red flag is saying you would inject the raw Request object and manually extract headers or path parameters from its scope or headers dict. Another is suggesting you must gather the values in the path operation function and then pass them into a regular helper function; this misses the point of the DI system entirely. A third error is claiming that dependencies can only read from one source type or that you need a special class or decorator to enable multi-source resolution.

What usually comes next

The interviewer may ask how class-based dependencies work, in which case the answer is that FastAPI resolves the init parameters the same way. They might ask about dependency caching across a single request, or how to handle validation errors inside dependencies. They could also ask what happens when a dependency parameter name clashes with a path operation parameter name, testing whether you understand that scopes are independent.

A concrete example

Imagine an endpoint GET /items/{item_id} that needs a dependency requiring the item_id from the path and an X-Api-Version from the header. You define async def get_item_context(item_id: int = Path(...), api_version: str = Header(..., alias="X-Api-Version")): and return a context object. In the endpoint, you declare async def read_item(context: ItemContext = Depends(get_item_context)). FastAPI sees the dependency, inspects get_item_context, sees Path on item_id and Header on api_version, resolves both from the incoming request, and injects them automatically.

Interview question

You need a FastAPI dependency that combines a path parameter and a request header. What is the correct implementation pattern?

  • a.Use a special @composite_dependency decorator on the function to tell FastAPI to resolve parameters from multiple request locations.
  • b.Inject the raw Request object into the dependency and manually read the path parameter and header from its scope and headers dictionary.
  • c.Extract both values in the path operation endpoint and pass them into a plain helper function called directly from the endpoint.
  • d.Annotate each parameter in the dependency function with its source (e.g., Path, Header) and declare the function as a dependency with Depends().Correct
Why?

FastAPI inspects dependency signatures using the same resolution engine as endpoints, so annotating parameters with Path, Header, or similar and using Depends() lets the framework inject them automatically. Option B is tempting for developers familiar with lower-level frameworks, but manually parsing Request bypasses validation and defeats the purpose of FastAPI's dependency injection system.

Just read this? Test yourself on what you have been reading.

Read the original → fastapi.tiangolo.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on fastapi — each one lists the topics its interview covers.

See open roles