The REST API and “headless” ideas

The WordPress REST API is the built-in interface that lets the block editor, mobile apps, and other tools read and write site data over HTTP. It is enabled by default, and turning it off completely usually breaks the admin experience. A “headless” setup means a separate front end talks to that same API while WordPress stays the origin; you still need caching, authentication, and routine patching on the WordPress side.

When the block editor stops saving

If wp-admin feels broken after you installed a plugin that “disables REST,” rename that plugin’s folder first so WordPress can load without it. Then confirm the endpoint responds:

curl -sI https://example.com/wp-json/ | head

You want a normal JSON-related response, not a hard 404 from a security rule that blocked the whole API. Public user listing through /wp/v2/users is a common concern. Many sites lock down that route alone instead of killing every REST path. A full disable is why Gutenberg cannot save and why official apps cannot connect.

Limiting abuse without breaking admin

Unauthenticated traffic that hammers /wp-json/, runs heavy searches, or tries to create users belongs under rate limits and proper auth. On our shared platform, LiteSpeed and the server security stack can throttle noisy requests. Use application passwords for any integration that must write data. Leave xmlrpc closed if you do not need it; two open write doors do not improve reliability.

• Restore /wp-json/ so the block editor works again.
• Restrict routes you actually dislike, such as public user enumeration.
• Issue application passwords only to trusted apps and revoke them when finished.

What headless still requires

A React or similar front end that calls /wp-json/ is still WordPress on the origin server. LiteSpeed Cache does not treat those JSON routes like ordinary HTML pages by default. Plan to cache public GET responses, never cache authenticated or cookie-bearing JSON, and purge when you publish. The Node host is a second place for TLS, DDoS exposure, and forgotten updates. The front end does not remove wp-admin, plugin risk, or the need to patch WordPress; it often adds CORS configuration as well.

Work in this order: restore the API, confirm Gutenberg saves, then tighten only the routes you need to restrict. Headless is an architecture choice, not a security toggle. If you only wanted to hide users, hide that endpoint. Cache public GETs at LiteSpeed or the front-end layer with a purge on publish, and keep application passwords for any headless write path. If /wp-json/ feels slow, inspect plugins that register large numbers of custom routes before blaming the API itself.