Katkat

Exposing a Python Function as a REST Endpoint with FastAPI and Unit Testing It

EngelhartSoftware Engineer · Technical Screen

Last 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

  1. Describe a REST API endpoint you have implemented, or how you would implement one for the function above.
  2. Does FastAPI count as a REST endpoint?
  3. 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

  1. How do you normally unit test your code?
  2. 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?