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.
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.