Personal Catalogue: PHP & MySQL — Chapter 10, Exercise 3 ==================================================== TASK Build api_search.php from this chapter, visit it directly in a browser with a real search term (e.g. api_search.php?q=Python), and confirm the response is genuine, valid JSON — not an HTML page — by checking the response's own Content-Type header and validating the body with a JSON linter or a small PHP one-liner. SOLUTION With api_search.php built exactly as shown in the chapter (including the header('Content-Type: application/json') call before any output), and at least one real item in the database with "Python" in its title or creator (e.g. "Fluent Python" from earlier chapters), visit: api_search.php?q=Python Checking the response headers, e.g. via curl: curl -i "http://localhost/catalogue/api_search.php?q=Python" Expected output includes a header line: Content-Type: application/json confirming the response is genuinely declared as JSON, not the default text/html PHP would send otherwise. Checking the response body itself is valid JSON: curl -s "http://localhost/catalogue/api_search.php?q=Python" | php -r 'var_dump(json_decode(file_get_contents("php://stdin"), true));' Expected output: a real PHP array structure printed by var_dump(), something like: array(1) { [0]=> array(3) { ["id"]=> int(1) ["title"]=> string(13) "Fluent Python" ["creator"]=> string(16) "Luciano Ramalho" } } If json_decode() had failed (e.g. because the response wasn't actually valid JSON), var_dump() would print NULL instead of a real array — confirming the body parses correctly is what proves it's genuine JSON, not just text that happens to look JSON-like. WHY THIS WORKS AS AN ANSWER ---------------------------- It checks both the declared Content-Type header and the actual parseability of the response body — two genuinely separate things, since a server can claim application/json while sending malformed text — rather than only eyeballing the response and assuming it looks correct.