The habit REST debugging teaches you doesn't transfer

Debugging a REST API on iOS usually starts with the URL and the method: GET /v1/users/42 failing tells you a lot before you've even opened the response. GraphQL removes that signal almost entirely. Every operation — a query, a mutation, a subscription — is typically a POST to the same single endpoint, so a request list that only shows method and path renders every GraphQL call identically. Worse, GraphQL frequently returns HTTP 200 even when the operation itself failed — errors live inside the response body, not the status code, which breaks the "scan for the red rows" habit REST trains into you.

Where the real information is

Three things actually distinguish one GraphQL request from another, and none of them are in the URL:

  • Operation name and type — sent in the request body, this is the closest equivalent to a REST endpoint name. A capture tool that surfaces this per-request (instead of just "POST /graphql" forty times) turns an unreadable list back into a scannable one.
  • Variables — the actual input to the operation, equivalent to query parameters or a request body in REST. This is usually where a bug actually lives: the wrong ID, a missing field, an unexpected null.
  • The errors array in the response — GraphQL's spec defines a top-level errors field that can be present alongside a 200 status and partial data. A failed field inside an otherwise-successful response is a real, common state that status-code-only debugging misses entirely.

A practical debugging order

  1. Find the operation by name, not by scanning identical POST rows.
  2. Check the response body's errors array before assuming a 200 means success.
  3. Check the variables that were actually sent — a surprising number of "backend bugs" turn out to be a client sending the wrong input.
  4. If it's intermittent, replay the exact same operation and variables a few times and see whether the result is actually consistent — GraphQL resolvers commonly touch multiple backend services, and a flaky one downstream can look like a flaky client bug.

Why this matters more on-device

GraphQL debugging tools built for a browser dev console assume you're already looking at the network tab of the exact client making the request. On iOS, that same visibility requires a proxy that specifically understands and decodes GraphQL's request/response shape — otherwise you're stuck reading raw JSON bodies and reverse-engineering the operation name yourself. Hollowport decodes GraphQL operations automatically for exactly this reason.