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.