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

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? ```hint 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. ``` #### 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. ```hint 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. ``` #### 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 ### What a Strong Answer Covers - A correct short answer on what FastAPI is, followed by the mechanism behind an endpoint - An endpoint design with sensible paths, methods, validation and status codes - Business logic kept outside the request handler so that it can be tested directly - A concrete, runnable test example with edge cases and a replaced dependency - An honest account of one's own experience, with specifics ### 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?