REST vs GraphQL vs gRPC

REST is the default, but not the only option. GraphQL lets clients ask for exactly the data they need in one request; gRPC offers fast, strongly typed calls between services. Each solves real problems – and adds its own. Senior engineers are expected to explain the trade-offs, not just name the technologies.

One screen, three styles

A course page needs the course title, its instructor's name and the latest three reviews.

# REST – resources; may take several requests, may return fields you don't need
GET /api/courses/rest-api                 → { id, title, description, price, instructorId, … }
GET /api/instructors/u7                   → { id, name, bio, avatarUrl, … }
GET /api/courses/rest-api/reviews?limit=3 → [ … ]

# GraphQL – one endpoint; the client describes the exact shape it wants
POST /graphql
query {
  course(id: "rest-api") {
    title
    instructor { name }
    reviews(last: 3) { rating comment }
  }
}

# gRPC – a typed contract in a .proto file; binary messages over HTTP/2
service CourseService {
  rpc GetCoursePage (GetCoursePageRequest) returns (CoursePage);
}
message GetCoursePageRequest { string course_id = 1; int32 review_count = 2; }

Over-fetching and under-fetching

• Over-fetching: REST's /courses/rest-api returns the description and price even when the screen only needs the title.
• Under-fetching: the screen needed three round trips. On a slow mobile network, that's noticeable.

REST has answers too – field selection (?fields=title,instructor.name), embedding (?include=instructor), or a purpose-built endpoint for a screen (the "backend for frontend" pattern). GraphQL makes this flexibility the core of the design.

Comparison

Choosing

Practice

Summary