The WordPress REST API has been available as a feature plugin for a while, and version 2 is stable enough that we used it as the backend for a client's companion mobile app this quarter rather than building a bespoke API on top of custom post types.
Registering custom endpoints for the client's event listings took less code than we expected — the plugin's route registration API handles argument validation and permission callbacks in a way that felt familiar coming from other framework routing systems we use. Authentication via OAuth1 (the current recommended approach until basic auth or JWT plugins mature) was straightforward to wire into the mobile client, even though setting up the initial OAuth handshake took more back-and-forth with the client's app developer than a simpler API key would have.
The editorial team keeps using the WordPress admin they already know, and the app just reads from the same database through the REST layer instead of us building and maintaining a parallel CMS. This turned out to be the biggest practical win: the client's marketing staff publish an event the same way they always have, through a familiar WordPress screen, and it shows up in the mobile app automatically with no separate publishing step and no risk of the two systems drifting out of sync.
We also had to think about versioning early, even though the plugin itself is still evolving underneath us. Rather than have the mobile app call the REST API's routes directly with no separation, we wrapped the endpoints the app actually depends on behind a thin, clearly namespaced route prefix of our own, so a future breaking change in the underlying plugin's core routes does not automatically become a breaking change for an app already live in app stores and outside our ability to force an instant update.
Performance needed a little extra attention. The default REST responses for post-type collections include more fields than a mobile client actually needs — full rendered content, GUID, several link relations — so we trimmed the response down with a custom field filter to keep payloads small on what is often a slower mobile connection at an event venue. We also added a short cache layer in front of the more frequently hit endpoints, since the mobile app polls for updates rather than using any kind of push mechanism yet.
We would not yet recommend this for anything that needs to be bulletproof — it is not core WordPress, and the plugin landscape around auth is still shifting, with basic auth plugins explicitly marked as development-only and JWT support still maturing across the ecosystem. But for a companion app with a forgiving audience and a client team who values keeping one system of record, it saved weeks of backend work compared to building and maintaining a separate API from scratch.