1 · Web apps for ML & the request/response model
A trained model in a file can't be used by anyone — it needs a front end. The web gives you two: a REST API for other systems, and a dashboard for humans. Both ride on the same HTTP request/response round-trip, the foundation of every web app you'll build.
One idea, one try. At your own pace.
LEARN BY DOINGPut your intuition to work3 steps
1 · Web apps for ML & the request/response model
Use the lesson’s examples and explanation to check your idea.
Personal reflection. Nothing is sent to an AI service.A web app exposes your model over HTTP via the request/response round-trip: a CLIENT sends a request to a SERVER route, a handler runs (parse → `model.predict` → build a response), and the server returns a response with a STATUS CODE and a body (JSON for systems, HTML for humans). A REST API serves other programs; a dashboard serves people — but both are the same round-trip underneath.
Without this:
Without a front end your model stays a `.joblib` file nothing can call — no other system can request a prediction, and no non-technical user can ever see one.
You spent the whole bootcamp turning data into a trained model and saving it as a .joblib artifact. That artifact is the brain — but right now nobody can talk to it. A model in a file can't take input from a user, can't answer another program, can't do anything until something calls it. That "something" is a web app.
There are two audiences, and they want two different front ends:
1. A REST API — for other systems. A mobile app, a billing service, another team's backend: machines that want a prediction send a structured request and expect a structured answer back, usually JSON ({"prediction": 1, "probability": 0.83}). No buttons, no colors — just data in, data out. This is what you build with Flask (this chapter) or FastAPI (the MLOps track).
2. A dashboard — for humans. A risk analyst, a sales rep, your boss: people who want to type a few values into a form, click a button, and see a prediction rendered on a page. They need HTML, inputs, and a readable result — not raw JSON. This is what Streamlit (Chapter 3) makes effortless.
Both run on the same engine: the HTTP request/response round-trip. This is the single most important idea in web development, and it never changes:
- A client (a browser, a phone app, a
curlcommand) sends a request to a specific URL on a server. - The server matches that URL to a route — a function you wrote to handle it.
- The handler runs: it parses the incoming data, does the work (for us:
model.predict), and builds a result. - The server sends back a response: a status code (did it work?) plus a body (the data, as JSON or HTML).
- The client receives the response and uses it — a program reads the JSON, a browser renders the HTML.
Methods say what you want. The request carries an HTTP method. GET means "give me something" (fetch a page, read data — no side effects). POST means "here's data, do something with it" (submit a form, send features to /predict). Predictions almost always use POST because you're sending the feature values in the request body.
Status codes say what happened. Every response carries a 3-digit code so the client knows the outcome without guessing: 2xx = success (200 OK), 4xx = the client's fault (400/422 bad input, 404 not found), 5xx = the server's fault (500 something crashed). A robust API picks the right code so callers can react correctly — retry a 500, fix the request on a 400.
The scene below animates the full round-trip for a /predict request: watch the request travel down into the server, the model run, and the response travel back up to the browser. Everything else in this track — Flask routes, JSON APIs, forms, Streamlit dashboards — is just a variation on this one loop.
The HTTP round-trip: the request travels down to the server (blue), the response back up to the browser (green).
A browser sends `POST /predict` with a JSON body of features. In the correct order, what is the HTTP request/response round-trip?
- A trained model needs a web front end to be usable: a REST API (JSON) for other systems, and a dashboard (HTML) for humans.
- Every web app runs on the HTTP request/response round-trip: client sends a request → server route → handler runs → server returns a response → client reads it.
- The method says what you want (`GET` = fetch, `POST` = send data) and the status code says what happened (2xx success, 4xx client error, 5xx server error).
Every deployed model — from a fraud-scoring API to a churn dashboard — is reached through exactly this round-trip; the request carries the features, the response carries the prediction.
If you remove it: With no request/response layer the model can't be called at all — it's a file on disk that no system and no person can ever query for a prediction.