Is this a real GraphQL-to-REST compiler?

No — it's explicitly a best-effort heuristic helper. It suggests plausible REST verb+path pairs from naming conventions and top-level field shape, but it doesn't generate a working REST API, resolve types, or understand your actual data model.

How does it decide the REST verb and path for a query field?

Every top-level query field maps to GET / . If that field takes an argument literally named "id" (case-insensitive), the suggested path becomes GET / /:id instead, since that's the common convention for "fetch one resource by id".

How does it decide the REST verb and path for a mutation field?

By the field name's prefix: create or add → POST / ; update or edit → PATCH / /:id; delete or remove → DELETE / /:id; anything else defaults to POST / , since most other mutations still represent some kind of write.

What about nested selections and subscriptions?

A field with a nested selection set gets a note suggesting a nested resource path or a ?include= query parameter, since REST typically needs a separate call or query param for related data GraphQL fetches in one shot. Subscription fields are flagged as having no direct REST equivalent, since REST doesn't have a push-based analogue — WebSockets or Server-Sent Events are suggested instead.

GraphQL to REST Mapping Helper - Suggest REST Endpoints

Overview

Introduction

Teams migrating away from a GraphQL API, or standing up a REST facade in front of one, often start by sketching out which REST endpoint each GraphQL operation roughly corresponds to, which usually means re-reading the same queries and mutations by hand over and over.

This tool automates the first pass of that sketch: paste a query, mutation, or subscription, and get a suggested REST verb and path per top-level field, entirely in your browser.

What Is GraphQL to REST Mapping Helper?

A small GraphQL document parser paired with a naming-convention-based REST mapping heuristic, not a schema-aware compiler.

It's part of this site's API Tools collection and runs entirely client-side; nothing you paste in is sent anywhere.

How GraphQL to REST Mapping Helper Works

The operation type (query, mutation, or subscription) and name are read from the start of the document, then the top-level selection set is walked to list each field's name, alias, argument names, and whether it has its own nested selection set — nested fields themselves aren't walked, only flagged as present.

Each top-level field is then mapped independently: query fields become GET requests (with an :id path segment when an id argument is present), and mutation fields become POST/PATCH/DELETE based on their name's prefix, following the rules described in the FAQ.

When To Use GraphQL to REST Mapping Helper

Use it early in a GraphQL-to-REST migration or REST-facade design, to get a rough first draft of endpoint names before refining them by hand.

It's also useful just to think through what a GraphQL operation would look like as a set of REST calls, when explaining an existing GraphQL API to someone more familiar with REST conventions.

Often used alongside GraphQL Query Tester.

Features

Advantages

Parses real GraphQL syntax (aliases, arguments, directives, nested selections) rather than relying on naive string matching, so it copes with realistically formatted queries.
Applies a consistent, explainable naming heuristic instead of a black-box guess, so every suggestion can be traced back to a simple rule.
Flags nested selections and subscriptions explicitly instead of silently mis-mapping them, so you know where the heuristic needs human judgment.

Limitations

This is a heuristic, not a real compiler: it has no knowledge of your actual schema, resolvers, or data model, and its suggestions are a starting point to refine, not a finished API design.
Only top-level fields are mapped; nested selections are flagged as suggesting a nested resource or ?include= parameter, but never mapped to their own endpoint automatically.
Fragment spreads (...FragmentName, ... on Type) aren't specially resolved and are simply skipped over while scanning for field selections.

Examples

Mapping a query with a by-id lookup and a nested selection

Input

query GetUserWithPosts {
  user(id: "123") {
    id
    name
    posts {
      id
      title
    }
  }
  categories {
    id
    name
  }
}

Output

Operation: query GetUserWithPosts

Suggested REST mapping (heuristic best-effort — verify against your actual API design):

- user -> GET /user/:id
    Has nested selections — consider a nested resource path or a `?include=` query parameter to fetch that related data.
- categories -> GET /categories
    Has nested selections — consider a nested resource path or a `?include=` query parameter to fetch that related data.

user takes an id argument so it gets a :id path segment; categories has no id argument so it maps to a plain collection GET. Both carry a nested-selection note since both select subfields.

Best Practices & Notes

Best Practices

Treat every suggestion as a starting point: rename paths to match your team's existing REST conventions before treating this as a design document.
Pay special attention to mutations that fall into the "otherwise → POST" default; those are the ones most likely to need a human-chosen verb and path.
Use the nested-selection notes as a prompt to decide, case by case, whether a related field should become its own endpoint, a nested route, or a ?include= parameter.

Developer Notes

Top-level fields are located with a small hand-written brace-depth-tracking scanner rather than a full GraphQL grammar parser, since graphql-query-tester.ts (this category's other GraphQL tool) only forwards the raw query string to a live endpoint and doesn't parse GraphQL syntax at all; nested selection sets are detected and skipped over wholesale rather than walked, since the REST-mapping heuristic only ever applies to an operation's direct fields.

GraphQL to REST Mapping Helper Use Cases

Drafting a first-pass REST endpoint list while planning a GraphQL-to-REST migration
Explaining what a GraphQL operation "means" in REST terms to a team or client more familiar with REST
Spot-checking naming consistency across a set of GraphQL mutations (create/update/delete prefixes) before they're exposed any other way

Common Mistakes

Expecting nested fields to get their own suggested endpoint automatically; only top-level fields are mapped, nested ones are only flagged.
Assuming a mutation without a create/add/update/edit/delete/remove prefix was mis-handled; it intentionally falls back to a generic POST suggestion.

Tips

Name your mutations with clear create/update/delete-style prefixes if you want this tool's suggestions to need less manual correction afterward.
Run each top-level field of a large query through this tool separately if you want to focus on refining one suggested endpoint at a time.

GraphQL to REST Mapping Helper