Implement a Middle-Tier REST API Server for Camera Log Ingestion and Queries

Cameras produce logs. Implement the **middle-tier API server** that sits between users and cameras: cameras send their logs to the server, and users send requests to the server to get those logs back. Where the logs come from is out of scope. The tests create fake logs and exercise only the API's behavior, so your job is the HTTP interface, its request handling, and whatever storage it needs to answer requests. Write the server by hand in a language and HTTP framework of your choice, including routing, request parsing, validation, and response codes. A lightweight framework such as Flask is enough. ```hint Pin down the contract before the handlers Write out each endpoint's method, path, request body, success response, and error responses before you write any handler. Much of the difficulty in this exercise lies in understanding exactly which behavior is expected. ``` ```hint Store logs for the questions users ask Organize what the server keeps around the lookups users will make, so that answering a request does not mean scanning every log from every camera. ``` ### Constraints and Clarifications - Log generation is out of scope. Assume a camera, or a test acting as one, calls your API with log data. - The exercise is about API behavior. Persistence beyond the life of the process is not required unless the interviewer asks for it. ### Clarifying Questions - What fields does a log entry have (for example, a timestamp, a severity, a message), and do cameras send one entry per request or batches? - Which queries do users need: all logs for one camera, a time range, the most recent entries, or filtering by severity? - Do users only read logs, or can they also send a request that the server must relay to a camera? - How should the server respond to unknown cameras, malformed entries, or duplicate submissions? - Is there a limit on how many entries a single response may return, and should results be paginated? - Do requests need authentication, for example to stop one user from reading another user's cameras? ### What a Strong Answer Covers - A clear endpoint design for camera ingestion and user queries, with request and response formats - Input validation and correct HTTP status codes for success and for each error case - A storage layout that makes the supported queries efficient and returns results in a defined order - Thread safety when requests are handled concurrently - Tests that feed fake logs through the API and check both the normal paths and the errors ### Follow-up Questions - Many cameras now send logs continuously. What breaks first in your server, and how would you scale ingestion and storage? - Users want new logs pushed to them as they arrive instead of polling. How would you change the API? - A camera times out and resends the same batch. How do you avoid storing the entries twice? - Logs may be kept only for a limited period. How would you enforce retention without slowing down requests?