Exercise 3: What Headless WordPress Actually Means, and the REST API's Role — Possible Solution
====================================================================

WHAT HEADLESS WORDPRESS ACTUALLY MEANS, PER THIS CHAPTER
------------------------------
Per this chapter, headless WordPress is "WordPress used purely as a
content-management backend, with the actual presentation layer built
entirely separately." Concretely: a completely separate front-end
application, "built in React, Vue, or any other framework, with no PHP
templates and no theme system involved at all," handles everything a
visitor actually sees, while WordPress's own dashboard, database, and
content-editing tools continue to be used purely for managing and
storing the content itself.

WHY THIS IS A GENUINE DEPARTURE FROM EVERYTHING ELSE IN THIS COURSE
------------------------------
Every other chapter in this course - theme anatomy, the template
hierarchy, the Loop - is entirely about WordPress generating HTML
directly through PHP templates and the theme system. Headless
WordPress abandons that whole rendering pipeline entirely for the
front end: none of the theme files, the template hierarchy, or PHP
template tags this course has spent five chapters covering are used at
all in a headless setup. WordPress still exists and still holds the
content, but a completely different technology stack is responsible
for actually displaying it.

THE SPECIFIC ROLE THE REST API PLAYS
------------------------------
Per this chapter, "because content is available as structured JSON, a
completely separate front-end application... can consume that JSON
directly instead of relying on WordPress's own HTML rendering." The
REST API is the literal bridge connecting the two halves - it's the
mechanism through which the separate front-end application actually
retrieves the content (posts, pages, custom post types) that lives in
WordPress's own database, formatted as structured JSON rather than
pre-rendered HTML. Without the REST API (or something functionally
equivalent to it), the separate front-end application would have no
way to access WordPress's own content data at all.

WHY THIS CONNECTS THIS ENTIRE CHAPTER TOGETHER
------------------------------
Everything else covered in this chapter - the built-in /wp-json/
endpoints, genuine REST semantics, custom post type exposure via
show_in_rest - exists specifically to make this headless pattern
possible. Headless WordPress isn't a separate feature bolted onto the
REST API; it's the natural architectural consequence of WordPress's
content already being available as structured, fetchable JSON in the
first place.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines headless WordPress precisely using this chapter's own
wording, contrasts it explicitly against the PHP-template-based
approach the rest of the course has taught, and explains specifically
and concretely what role the REST API plays as the connecting
mechanism rather than describing the two as merely related.