Exercise 2: Why /docs Needs a Deliberate Production Decision — Possible Solution ==================================================================== WHY CHAPTER 1 CALLED IT A GENUINE ADVANTAGE ------------------------------ /docs gives a fully working, interactive API explorer generated automatically from the route definitions and Pydantic schemas already written for validation - genuinely useful for testing routes directly in the browser during development, with no extra setup required at all, something none of the three sibling courses get for free. WHY THAT SAME FEATURE NEEDS A SECOND LOOK BEFORE PRODUCTION ------------------------------ /docs doesn't just describe the API - it lets anyone who visits it actually make real API calls against the running application directly through that page. What's a convenient development tool becomes, in production, a public interface anyone on the internet could use to explore and interact with the live API, whether or not that was actually intended. WHY THE DEFAULT SHOULDN'T BE LEFT AS-IS ------------------------------ Leaving /docs enabled in production isn't inherently wrong, but it should be a decision the developer actually makes, weighing whether public interactive access to the API is genuinely wanted - not something left exposed simply because it was never turned off. The conditional docs_url setting makes that choice explicit rather than accidental. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly explains why /docs is genuinely valuable during development, correctly explains what changes about its risk profile once the app is live in production (public, unrestricted interactive access), and correctly frames the recommendation as making a deliberate choice rather than simply disabling it outright or leaving it on by accident.