The WordPress REST API
WordPress Intermediate/Advanced
Chapter 6 · The WordPress REST API
Every prior chapter has covered WordPress generating HTML through PHP templates. This chapter covers its other, built-in way of exposing content: as structured JSON, through a real, genuine REST API — no plugin required, and a perfect concrete application of everything API Types & Design already covered in the abstract.
It's Already There, On Every WordPress Site
Since WordPress 4.7 (2016), every WordPress install automatically exposes its own REST API at /wp-json/ — nothing needs to be installed or enabled for basic read access to work.
| Endpoint | Returns |
|---|---|
/wp-json/wp/v2/posts | A list of published posts, as JSON |
/wp-json/wp/v2/posts/42 | A single post by ID |
/wp-json/wp/v2/pages | A list of pages |
/wp-json/wp/v2/categories | A list of categories |
/wp-json/wp/v2/users | A list of users (public fields only, by default) |
Genuine REST, Not a WordPress-Specific Invention
This is a real, concrete instance of everything API Types & Design already covered: resources identified by URLs, HTTP methods carrying meaning (GET to read, POST to create, PUT/PATCH to update, DELETE to remove), and JSON as the response format.
Authentication — Reading Is Open, Writing Isn't
GET requests to public content work with no authentication at all — anyone can fetch the JSON above directly. Creating, editing, or deleting content requires real authentication: application passwords (a WordPress-generated credential meant specifically for API access) or a cookie-plus-nonce combination for requests made from a logged-in browser session.
Exposing a Custom Post Type — A Real, Easy-to-Miss Gotcha
portfolio custom post type from WordPress Intermediate/Advanced 4 does not automatically appear in the REST API — register_post_type()'s own show_in_rest argument defaults to false. Forgetting this argument is a genuine, common source of confusion: the post type works perfectly in the dashboard and on the front end, yet /wp-json/wp/v2/portfolio simply doesn't exist until it's explicitly enabled.
A First Look at Headless WordPress
Because content is available as structured JSON, 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 — can consume that JSON directly instead of relying on WordPress's own HTML rendering. This pattern is called headless WordPress: WordPress used purely as a content-management backend, with the actual presentation layer built entirely separately.
Hands-On Exercises
A developer registers a "portfolio" custom post type exactly as shown in WordPress Intermediate/Advanced 4, then visits /wp-json/wp/v2/portfolio expecting to see JSON data, but gets an error instead. Explain why, and what's missing.
📄 View solutionExplain why a GET request to /wp-json/wp/v2/posts works with no authentication, while a POST request to the same endpoint requires it, connecting your answer to what each HTTP method actually represents.
📄 View solutionExplain what "headless WordPress" actually means, and specifically what role the REST API plays in making it possible at all.
📄 View solutionChapter 6 Quick Reference
- Every WordPress site exposes a real REST API at /wp-json/ automatically, since WordPress 4.7
- Genuine REST: resources as URLs, HTTP methods carry meaning, JSON responses — a real application of API Types & Design's own material
- GET requests to public content need no authentication; write operations require application passwords or cookie+nonce
- show_in_rest defaults to false — a custom post type needs it explicitly set to true to appear in the REST API at all
- Headless WordPress — a separate front-end framework consuming the REST API directly, with no PHP templates or theme involved
- Next chapter: Enqueuing Scripts & Styles Properly