What is building an API?
An API is the set of endpoints your client calls. Building one means defining routes, writing handlers that read the request and return a response, and shaping the JSON and status codes consistently. It is the server side of the contract you defined earlier.
Why it matters
The API is the bridge between your UI and your data, and as a full-stack developer you design both ends to fit together. A clean, predictable API makes the client simple; a messy one makes everything downstream harder. This node is the foundation the seam and auth stages build on.
What to learn
- Defining routes and HTTP methods
- Reading params, query, and body
- Returning JSON with correct status codes
- A consistent response and error shape
- Middleware for cross-cutting concerns
- CRUD endpoints for a resource
- Designing the API for the client that consumes it
Common pitfall
Returning 200 OK for everything, including errors, with the real status hidden
in the body. The client then cannot branch on the status code, caching breaks,
and error handling gets fragile. Use correct status codes — 201, 400, 404,
500 — so both halves and the tooling can rely on them.
Resources
Primary (free):
- MDN — HTTP methods · docs
- Hono — Routing · docs
- Microsoft — REST API design · docs
Practice
Build CRUD endpoints for one resource: list, get, create, update, delete, each with the right method and status code and a consistent error shape. Call them from the client fetching node so both halves work together. Done when the verbs, codes, and shapes are consistent end to end.
Outcomes
- Define routes and handlers returning JSON.
- Use correct status codes for each outcome.
- Apply middleware for cross-cutting concerns.
- Design the API to fit the client that calls it.