An API is the contract a client uses to ask a system to do work. In an interview, that contract has to make the main user actions easy and predictable, like creating a note, reading it back, editing it, deleting it, and sharing it with someone else. It also has to prevent unsafe ambiguity, like two different endpoints that both “sort of” update a note but behave differently under the same input. Let’s ground that contract in a smallest-possible Notes app where a mobile or web client talks to one backend service that stores notes in a database.
Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
In that baseline design, the client sends an HTTP request to the API service, the API service validates it and applies the rules of the contract, and the database stores note records so future reads return the same state. The key point is agency. The client chooses what to call, the API service decides what is allowed and what gets written, and the database persists the result so the next request can observe it. This is the shape we will stress later when a single server stops being enough.
The simplest working API names resources clearly and ties each endpoint to one user action and one stored object shape. A note is an object with an id, ownerUserId, title, body, and timestamps, and sharing adds a rule that another user can read or edit based on a permission. With that, a small endpoint set can cover the core flow without inventing extra verbs or overloaded meanings. The mapping from each endpoint to a read or write path is what keeps the contract legible under pressure. Let’s map those endpoints onto the baseline service and database reads and writes.