Choosing an API style, REST vs GraphQL vs tRPC vs gRPC

A dressmaker can buy cloth in four ways.

At the fabric shop	In the system
pre-cut bundles on hooks, each a fixed mix of pieces	REST resources (step 1)
a dress needing three bundles, each with pieces she will never sew	under- and over-fetching (step 2)
a cutting slip naming exact cloths and lengths, handed over once	a GraphQL selection (step 3)
the cutter unrolls and measures every line; a 500-line slip ties up the counter	resolvers per field, cost limits (steps 4–5)
bundles hang ready on hooks; a one-off slip is cut afresh each time, unless it is a numbered house kit	GETs reused, POSTed queries, persisted ids (steps 6–7)
the workroom's order pad, printed from the shop's own stock list	tRPC's shared type (step 8)
trade orders by cloth number; a renamed cloth keeps its number	protobuf field numbers (step 10)

In real terms: pick the style by who shapes the data, where it can be cached, who shares the contract, and whether a browser must call it.

Breaks down when: you expect the cutter to refuse an absurd slip on sight. A GraphQL server refuses only what a validation rule you wrote checks (step 5).

Contrasting case: one dressmaker buying one bundle. Every style costs one request then; the differences show only with several resources, repeats, renames or streams.

4.1 ExamHall: the room card four ways

EXH-1390: the proctor console's room card sent 10 REST requests per open and carried candidate fields it never showed. MR !1590 moves the console's nested views to one GraphQL query and keeps the exam paper on REST.

4.1 proctor console room card (3 candidates): HTTP requests · response bytes · data-layer calls
  REST, resource URLs          10 requests  1782 B  10 data-layer calls
  GraphQL, one POST query      1 request    256 B   10 data-layer calls
  tRPC, room.card procedure    1 request    192 B   10 data-layer calls (tRPC sent a GET)
  gRPC, RoomCardOf unary call  1 request    81 B    10 data-layer calls
  all four render the same card: true

REST pays in requests and bytes (step 2). GraphQL's one request still makes ten data-layer calls (step 4). The tRPC and gRPC procedures were written for this view. gRPC's figure is the protobuf message; the others are JSON bodies.

4.2 The exam paper and the browser cache

4.2 candidate app loads the ECON-201 paper 3 times; every answer carries Cache-Control: private, max-age=600
  REST GET /api/exams/ECON-201/paper   requests reaching the server: 1 (GET)
  GraphQL POST /graphql                requests reaching the server: 3 (POST)
  GraphQL GET, persisted query id      requests reaching the server: 1 (GET)
  tRPC query paper.get                 requests reaching the server: 1 (GET)
  gRPC puts each call's status in HTTP trailers; can a page's fetch() read trailers? false

Same header, different reuse: the method decides (steps 6, 7, 9). A page cannot read trailers, one reason gRPC needs a proxy (step 11).

4.3 A renamed field

4.3 the server renames candidate.seat to seatLabel; each client is unchanged, then built and run
  REST, hand-written type            tsc: 0 errors | runs: Ada Okafor · seat undefined
  tRPC, imports the router type      tsc: trpc-client.ts:7 TS2339 Property 'seat' does not exist on type '{ id: string; name: string; seatLabel: string; }'. | runs: not run: the build failed
  GraphQL, query in a string         tsc: 0 errors | runs: HTTP 200, errors: Cannot query field "seat" on type "Candidate".
  gRPC, old .proto (3 = seat)        server: seat_label = 3 | runs: Ada Okafor · seat B7

tRPC fails at build (step 8); REST silently shows undefined; GraphQL fails at run time, validated against the schema. gRPC keeps working: only field 3 travels (step 10).