What Is GraphQL? A Practical Introduction

GraphQL is a query language for APIs, paired with a server-side runtime that executes those queries against a typed schema. Where REST exposes many URLs, one per resource, GraphQL typically exposes a single endpoint — the client describes exactly what data it wants in the request body, and the server returns exactly that shape back.

The Core Idea: Ask for What You Need

A REST endpoint returns a fixed shape — if /users/42 includes ten fields and you need two, you get all ten anyway (over-fetching), and if you need data from three different endpoints to render one screen, that’s three round trips (under-fetching’s usual symptom). GraphQL flips this: the client sends a query describing the exact fields and nested relationships it wants, in one request, and gets back exactly that JSON shape — no more, no less.

query {
  user(id: "42") {
    name
    email
    orders {
      id
      total
    }
  }
}

Queries, Mutations, and Subscriptions

• Query — read data. The example above is a query.
• Mutation — write data (create, update, delete). Mutations use the same field-selection syntax to describe what the response should include after the write.
• Subscription — a long-lived connection that pushes updates to the client as the underlying data changes, typically over WebSocket.

The Schema

Every GraphQL API is backed by a strongly-typed schema defining every available type, field, and relationship. This is what makes introspection possible: a client (or a tool) can query the schema itself to discover exactly what’s queryable, without reading separate documentation that might be out of date.

GraphQL vs. REST

Neither replaces the other universally:

• GraphQL is a strong fit when clients have very different data needs from the same backend (a mobile app and a web app hitting the same API, wanting different field subsets) or when a screen needs data assembled from many underlying relationships in one round trip.
• REST stays simpler when your API is closer to a straightforward set of resources, when HTTP-level caching matters (GraphQL’s single endpoint, typically POST-only, doesn’t cache the way GET /users/42 does out of the box), or when you don’t want to take on a schema and resolver layer for a small API.

Authentication works the same way in both — a GraphQL API still expects credentials on the request, usually a bearer token in the Authorization header, the query and variables just travel in the POST body instead of the URL.

Testing GraphQL in HTTP Titan

HTTP Titan treats GraphQL as a first-class request type, not just a REST POST with a JSON string pasted in: a dedicated query and variables editor with GraphQL syntax highlighting, plus a schema panel that runs introspection against the endpoint so you can browse available types and fields directly instead of switching to separate documentation.