Exposing a Python Function as a REST Endpoint with FastAPI and Unit Testing It
EngelhartSoftware Engineer · Technical ScreenLast updated
An interview question on exposing a Python function as a REST API endpoint and testing it. It asks whether FastAPI counts as an endpoint, how an endpoint maps an HTTP request onto a function, and how you unit test such code, with a concrete example that covers edge cases and replaced dependencies.
Explain how you expose a Python function to other programs as a REST API endpoint, and how you unit test code like this. The questions came in the fundamentals half of a technical screen for a junior quantitative developer role; they started from experience ("Have you implemented a REST API endpoint?") and then moved to mechanics.
For concreteness, assume you have a pure Python function that computes a result from its inputs, for example the average of a price series over a date range, and that other services or a dashboard need to call it over HTTP.
Clarifying Questions
- Is the question about REST as an architectural style, or about the mechanics of a particular framework?
- Who will call the endpoint (internal services, a dashboard, analysts' scripts), and does it need authentication?
- Should the unit-testing example cover only the computation, or the HTTP layer as well?
Part 1 — Exposing a function as a REST endpoint
- Describe a REST API endpoint you have implemented, or how you would implement one for the function above.
- Does FastAPI count as a REST endpoint?
- How does an endpoint expose a function?
What This Part Should Cover
- What makes an API RESTful: resources, HTTP methods and their semantics, status codes, statelessness
- The distinction between a web framework and an endpoint
- The request path: routing, parsing and validating parameters, calling the function, serializing the result, reporting errors
Part 2 — Unit testing
- How do you normally unit test your code?
- Give one concrete unit test.
What This Part Should Cover
- The tools and shape of a test: a test runner, arrange-act-assert, parametrized cases
- Edge cases and failure paths, not only the happy path
- Isolating external dependencies with fakes or mocks, and what that hides
- Where unit tests stop and integration tests begin
Hints
Hint 1
Trace one request: Separate the tool you build with from the thing a client actually calls, then follow one HTTP request from the client to your function and back.
Hint 2
Isolate the unit: Pick a function whose output depends only on its inputs, list the inputs that could break it, and decide what to do about any dependency that talks to a database or the network.
Follow-up questions
- A caller sends a malformed date. What does your endpoint return, and where does the validation happen?
- The function reads prices from a database. How do you unit test it without the database, and what risk does that leave?
- How do you test the HTTP layer itself, rather than only the function behind it?
- The same expensive result is requested many times a minute. Where would you cache it, and how would you test the cache?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.