REST API vs WPGraphQL

REST API and WPGraphQL are two ways to expose WordPress content to other systems. The REST API ships with WordPress core and returns fixed JSON shapes per endpoint, while WPGraphQL is a plugin that exposes content via a single GraphQL endpoint where clients request exactly the fields they need.

When the WordPress REST API is the right choice

• The site stays mostly server-rendered with WordPress; the API is for integrations, not the primary front-end.
• You want zero additional plugin surface. The REST API is core, supported indefinitely.
• Your client code is comfortable with multiple round-trips and the standard /wp/v2/ JSON shape.
• Edge caching is a priority. REST endpoints cache cleanly at the CDN.

When WPGraphQL earns its complexity

• You’re building a headless front-end (Next.js, Astro, SvelteKit) that needs to compose pages from many content types in a single request.
• Mobile or constrained-bandwidth clients benefit from requesting only the fields they use.
• You have custom relationships between content types that map naturally to GraphQL’s connection model.
• Your front-end team has GraphQL experience and tooling (Apollo, Relay, urql) already.

Trade-offs to weigh

WPGraphQL is a third-party plugin: it’s well-maintained, but its release cadence and breaking changes are independent of WordPress core. REST is core: it’s slower-moving and less ergonomic for complex front-ends, but it survives plugin abandonment. Edge caching is easier with REST. Authentication is more standardized on REST (cookies, application passwords). Most production headless WordPress builds today use WPGraphQL; most integrations and partner APIs still use REST.