GraphQL vs REST for FHIR: 5 Questions to Decide

FHIR GraphQL is a real spec option in 2026, and some servers (HAPI, Aidbox, Medplum) support it alongside REST. GraphQL isn't better than REST — it's better for specific patterns. Five questions decide the fit.

1. Do you have complex nested queries with heavy _include chains? GraphQL's shape-driven query is cleaner than iterative REST _include:iterate. If your client code does 5+ REST calls to assemble a UI view, GraphQL cuts the round-trips.

2. Do multiple clients need different resource subsets? GraphQL clients declare their fields; the server returns only what's asked. REST returns full resources unless clients strip fields post-fetch. If you have 3+ apps with different display needs, GraphQL avoids over-fetching.

3. Is your team GraphQL-fluent? GraphQL requires client-side schema management, resolvers, and often a caching layer (Apollo, urql). REST is simpler operationally. Team fit matters more than technical fit.

4. Do you need FHIR's mutation semantics? GraphQL mutations for FHIR are less clean than REST — Bundle transaction semantics don't map naturally to GraphQL mutation semantics. If most writes are transaction Bundles, stick with REST.

5. Does your caching/edge story fit GraphQL? REST caches at HTTP layer; GraphQL requires custom cache logic. CDN-cached FHIR responses (common for public reference data) work better with REST.

When each wins

Vendor support (mid-2026)

Both are legitimate 2026 choices. Pick GraphQL for shape-driven reads with multiple client types; pick REST for straightforward CRUD, bulk data, and Bundle transactions.