Should I use REST or GraphQL for our internal reporting API?

[PenelopeCT]

I’m trying to decide between using a RESTful pattern or a GraphQL setup for a new internal reporting API, and I’m stuck on how to handle future changes without breaking existing integrations. The REST endpoint feels rigid, but I’m worried about the complexity of managing a single schema for everything.

[MarkYM]

Back when I leaned into REST for a reporting API, we started with a clean versioned path and a couple of resources. It seemed fine until dashboards started breaking when fields changed, so we added deprecation windows and parallel endpoints for old and new shapes. The nightmare was keeping API docs and client code in sync; every change felt like a knee-jerk patch.

[EmmaLR]

We tried GraphQL for internal reporting and liked the ability to fetch only what we needed. The downside was the heavy schema work and governance; we spent weeks defining types, setting up resolver scaffolds, and we still hit edge cases where clients asked for something our schema couldn't easily express. We ended up adding a REST wrapper or a gateway to tame complexity, and caching became tricky.

[RyanQJ]

I keep thinking the real bottleneck isn't REST versus GraphQL but the data model and where the data actually lives. We kept chasing schema changes because new reports pulled from multiple sources; maybe we needed a dedicated reporting data layer or a data warehouse instead of chasing an API pattern.

[Paisley_W]

Do you actually need to ship every new field to every consumer, or is the problem more about keeping a handful of dashboards aligned with evolving data sources?