docs: rest json api naming

[keydunov]

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
cubed3	🟢 Ready	View Preview	Apr 25, 2026, 5:08 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[claude]

Claude finished @keydunov's task in 2m 5s —— View job

---

Review of PR #10755 — Docs/REST JSON API naming

• Gather context and review the full diff
• Check naming consistency across all changed files
• Review non-rename changes (workbooks content, cursor rules)
• Check for missed occurrences of bare "REST" that should be renamed
• Post comprehensive review

---

Overall Assessment

This is a clean, well-executed documentation rename from "REST API" → "REST (JSON) API" across the Mintlify docs, paired with a new "Inspecting queries" and "Editing Semantic SQL by hand" section in the workbooks page. The PR is thorough and consistent. I have only minor observations.

Naming Consistency ✅

The rename is applied correctly across all 58 files. I verified:

• All prose references to "REST API" are updated to "REST (JSON) API" — confirmed via exhaustive grep.
• URL slugs, file paths, and route segments (rest-api/index.mdx, /reference/rest-api, [ref-rest-api]) are correctly left unchanged, per the naming guidelines.
• Third-party UI literals are preserved — Retool's "REST API" resource type and Budibase's "REST API" data source remain quoted verbatim.
• No plural "REST APIs" usage exists — consistent with the guideline to avoid the plural form.
• Protocol enumerations (e.g., "REST (JSON), GraphQL, and SQL") are consistently updated across introduction pages.
• docs.json navigation correctly shows "REST (JSON) API" as the group label while keeping the rest-api/index root path.

Only two remaining bare "REST API" strings exist in the entire docs tree, both correctly inside double-quotes referencing third-party UIs:

• retool.mdx:34 — Create a new "REST API" resource in Retool.
• budibase.mdx:42 — Create a new "REST API" data source in Budibase.

Cursor Rules (.cursor/rules/namings-rule.mdc) ✅

The new "Core Data API Naming" section is well-structured:

• Clear transitional naming guidance (REST API → REST (JSON) API → JSON API)
• Explicit carve-outs for URLs, file paths, code identifiers, env vars, and third-party literals
• Product taxonomy updated to list all four Core Data APIs with the transitional annotation

Workbooks Content (querying-data.mdx) ✅

The new "Inspecting queries" and "Editing Semantic SQL by hand" sections are well-written and add genuine value. The content:

• References inspect-query-tabs-v2.png and edit-semantic-sql-v2.png from static.cube.dev (consistent with other high-res screenshots in the repo)
• Properly links to Core Data APIs, REST (JSON) API, and GraphQL API using reference-style links at the bottom
• Uses the new "REST (JSON) API" naming from the start

Minor Observations

1. docs/introduction.mdx:91 — The phrase "REST (JSON) and GraphQL" (without "API") reads slightly awkwardly as a protocol enumeration. The original "REST and GraphQL" was more natural as a shorthand. Consider whether "REST (JSON) API and GraphQL API" would be clearer in this context, or leave as-is since it matches the parenthetical pattern used elsewhere.

2. docs/getting-started/cloud/query-from-react-app.mdx:3 — The description meta field uses "REST (JSON) or GraphQL endpoints" (no "API" suffix). This is fine for a compact meta description, just flagging for awareness that it's slightly different from the "REST (JSON) API" pattern used in body text.

3. No redirects needed — Since URL paths were correctly left unchanged, no redirect configuration is required.

Security / Performance / Testing

• No security concerns — this is a pure documentation change with no code, configuration, or API surface changes.
• No performance impact.
• Testing: the Mintlify preview build is the appropriate verification. No unit tests are affected.

Verdict

Looks good to merge. The rename is comprehensive and follows the naming guidelines precisely. The workbooks content additions are well-integrated.