GraphQL vs REST — What It Is and When It Actually Wins

GraphQL shows up in job posts and interview small-talk. The concept in five minutes:

The problem it solves

• Over-fetching: REST's /students returns 30 fields; your card needs 3
• Under-fetching: profile page needs /student + /marks + /attendance — three round trips

The GraphQL answer: ask for exactly what you need

POST /graphql
query {
  student(id: 42) {
    name
    cgpa
    marks(semester: 5) { subject grade }
  }
}

# response mirrors the query — nothing more, nothing less, ONE request

One endpoint, a typed schema, the client composes queries. The schema doubles as always-accurate API documentation.

The honest trade-offs

• HTTP caching (from the caching guide) mostly breaks — everything is a POST to one URL
• Server complexity: resolvers, N+1 query problems, query cost limits
• For a CRUD app with one client, REST is simpler and plenty

When each wins

GraphQL: many clients with different needs (mobile + web + partners), deeply nested data, rapid frontend iteration. REST: public APIs, simple domains, caching-heavy content. Fresher priority: master REST first — GraphQL is a two-day pickup once employed, and the interview answer above covers the conversation.