What should we choose for our internal API: REST or GraphQL?

[Jeffrey.R]

I’m trying to decide between using a RESTful design or a GraphQL endpoint for our new internal service API. The main issue is that our client teams keep changing their data requirements, and I’m worried about over-fetching with REST or making the GraphQL queries too complex.

[LilyCW]

I tried REST first and used sparse fieldsets and explicit includes, but we still ended up pulling in extra stuff because of nested relations and missing backend filters. It looked fine in docs, then in real use the payload ballooned whenever a team asked for related data.

[Hannah_J]

Switching to GraphQL did cut some over fetch, but the flip side was long, tangled queries and slow resolvers unless we put guardrails in place. We added query complexity checks, persisted queries, and timing dashboards to spot hot paths early.

[Daniel83]

Honestly I keep wondering if the problem isn’t the data shape at all but how we govern it. Teams keep changing requirements because boundaries aren’t clear and contracts drift. Maybe the real fix is process, not API style.

[AvaW]

I ran a small hybrid experiment: a gateway for the common paths and a separate query engine for the side requests. It bought us some control but the rollout slowed and we had to build adapters. Hard to tell if it was worth the extra maintenance.