Exercise 2: Why GET Needs No Auth but POST Does — Possible Solution
====================================================================

WHAT EACH METHOD REPRESENTS, PER THIS CHAPTER
------------------------------
Per this chapter, this API follows "HTTP methods carrying meaning: GET
to read, POST to create, PUT/PATCH to update, DELETE to remove." A GET
request is purely a request to READ existing, already-public
information - it doesn't change anything on the server. A POST
request, by contrast, is a request to CREATE new content - it
actively changes what exists on the site.

WHY READING PUBLIC CONTENT NEEDS NO AUTHENTICATION
------------------------------
Per this chapter, "GET requests to public content work with no
authentication at all - anyone can fetch the JSON above directly."
This makes sense because a GET request to /wp-json/wp/v2/posts is
simply requesting the same published content that's already publicly
visible on the ordinary HTML version of the site - anyone visiting the
site in a browser could already see this same content without logging
in, so requesting it as JSON instead of HTML doesn't expose anything
that wasn't already public.

WHY CREATING CONTENT REQUIRES AUTHENTICATION
------------------------------
Per this chapter, "creating, editing, or deleting content requires
real authentication: application passwords... or a cookie-plus-nonce
combination." A POST request would let whoever sends it add new
content to the site - if this were allowed without any authentication,
literally anyone on the internet could create arbitrary new posts on
someone else's WordPress site, which would obviously be a severe
security problem. Authentication proves the request is coming from
someone actually authorized to make changes, exactly the same
distinction WordPress Fundamentals 8's own role/capability system
draws for dashboard actions - just enforced here at the API level
instead.

WHY THIS IS A GENERAL REST PRINCIPLE, NOT A WORDPRESS-SPECIFIC RULE
------------------------------
This same read-vs-write authentication asymmetry is a standard pattern
across REST APIs generally, not something unique to WordPress - it
reflects the underlying distinction this chapter draws between GET
(safe, read-only) and POST/PUT/PATCH/DELETE (state-changing) methods,
and matches material API Types & Design already covers about HTTP
methods carrying real, meaningful distinctions rather than being
interchangeable ways to send a request.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains what GET and POST each represent per this chapter's own
method table, connects the authentication difference directly to the
real-world consequence of allowing unauthenticated writes, and
generalizes the reasoning as a standard REST API pattern rather than a
WordPress-specific quirk.