skip to content

Spec Structure

The shape of an OpenAPI document: its top-level keys, the operation object and its responses map, and what changed from Swagger 2.0 to 3.x. Interviewers ask so you can read and edit a spec by hand.

part ofAPI stylesoverview, primer and where to startread it →
on this pageshow

questions

5

In an OpenAPI 3.x document, what are the top-level keys and which are required?

level: juniorimportance: must knowfreq 72%

answer

  1. Eight root keys, only two always required
  2. Version string, metadata, hosts, endpoints
  3. components is inert until referenced
  4. paths required in 3.0, optional in 3.1

basics

~20 s

An OpenAPI 3.x document is one object whose root keys are openapi, info, servers, paths, components, security, tags and externalDocs. Only openapi and info are always required; 3.0 also requires paths, and 3.1 adds webhooks and jsonSchemaDialect.

solid answer

~40 s

An OpenAPI document is a single JSON or YAML object. `openapi` holds the spec version string (`3.0.3`, `3.1.0`) and tells tooling which parser to use; `info` carries the API's own metadata and requires `title` and `version`. `servers` is an array of base URLs, optionally templated with variables; if it is missing, the default is one server with url `/`. `paths` maps templated URL paths to Path Item Objects, each holding the HTTP method operations. `components` is an inert reuse registry — schemas, responses, parameters, securitySchemes and more — that does nothing until something references it. `security` sets document-wide auth requirements, `tags` declares grouping names for docs, `externalDocs` links out. Required: `openapi` and `info` in every version, plus `paths` in 3.0; 3.1 makes `paths` optional and adds `webhooks` and `jsonSchemaDialect`.

code

yaml · 31 lines
yaml
openapi: 3.0.3
info:
  title: Orders API
  version: 1.4.0
servers:
  - url: https://{region}.api.example.com/v1
    variables:
      region:
        default: eu
        enum: [eu, us]
paths:
  /orders/{orderId}:
    get:
      operationId: getOrder
      responses:
        '200':
          description: The order
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Order'
components:
  schemas:
    Order:
      type: object
      properties:
        id:
          type: string
tags:
  - name: orders
    description: Order lifecycle

go deeper

for a junior

Be ready to name the root keys and say what each holds, and to point at where a new endpoint would be added in an existing document.

for a middle

Explain the required-versus-optional split, why components is inert until referenced, and how server variables let one document cover several environments.

for a senior

Show judgment about document layout in a real repo: what belongs at the root, when to override servers per operation, and how root-level security and tags keep a large spec reviewable.

for a principal

Own the governance angle — whether one document or several describe the estate, how root metadata feeds the developer portal and gateway, and what the spec's structure commits every team to.

## What an OpenAPI document actually is An OpenAPI description is a single structured document — one JSON or YAML object, conventionally named `openapi.yaml` or `openapi.json` — that describes an HTTP API in a machine-readable way. Everything in it hangs off a small set of root keys. Knowing those keys by heart is what lets you open an unfamiliar 4,000-line spec, jump straight to the part you need, and review a diff without a generator in the loop. ## The two keys that are always required `openapi` is a string holding the version of the *specification* the document conforms to, such as `"3.0.3"` or `"3.1.0"`. It is not the API's version. Tooling reads it first to decide which rules apply, so a wrong value here makes the whole file unparseable. `info` is metadata about the API itself. It requires `title` and `version` (the API's version — often a semver string tied to your release train). Optional members include `description`, `termsOfService`, `contact` and `license`. OpenAPI 3.1 additionally allows `info.summary` and a `license.identifier` field carrying an SPDX identifier, mutually exclusive with `license.url`. ## Where the API is reachable: servers `servers` is an array of Server Objects. Each has a `url` — which may be relative and may contain `{variable}` placeholders — plus an optional `description` and a `variables` map. Each server variable declares a required `default` and optionally an `enum` of allowed values, which is how one document describes prod, staging and regional hosts without duplication. If `servers` is absent or empty, the effective value is a single server whose url is `/`, meaning "the host this document was served from". `servers` may also appear on a Path Item or an individual Operation, overriding the root value for that scope. ## The API surface: paths `paths` is a map from a templated path such as `/orders/{orderId}` to a Path Item Object. Keys must begin with `/` and are appended to the server URL. A Path Item Object holds an optional `summary` and `description`, the eight HTTP method fields (`get`, `put`, `post`, `delete`, `options`, `head`, `patch`, `trace`), a `parameters` list shared by every operation under that path, its own `servers` override, and may itself be replaced wholesale with a `$ref`. In 3.0, `paths` is required — even an empty object. In 3.1 it became optional, because a valid 3.1 document may describe only `webhooks`, or act purely as a shared `components` library. ## The reuse registry: components `components` holds named, reusable objects that have no effect unless referenced: `schemas`, `responses`, `parameters`, `examples`, `requestBodies`, `headers`, `securitySchemes`, `links` and `callbacks`; 3.1 adds `pathItems`. Component names must match `^[a-zA-Z0-9._-]+$`. Putting a schema in `components.schemas` does not publish an endpoint — it only makes the definition addressable. ## The cross-cutting roots `security` lists security requirements that apply to every operation by default; an operation can override or opt out. `tags` declares the tag names used to group operations, with descriptions and ordering that documentation renderers honour — operations reference tags by name, and undeclared tags still work but render without a description. `externalDocs` points at prose documentation. OpenAPI 3.1 adds two roots: `webhooks`, a map of named out-of-band operations the API *sends* to the consumer, and `jsonSchemaDialect`, which declares the default JSON Schema dialect for Schema Objects in the document. ## Extensions Anywhere the specification allows it, keys beginning with `x-` are specification extensions. Vendor tooling stores configuration there (code generators, gateways). Unknown non-`x-` keys, by contrast, are simply invalid and good linters will fail the build on them. ## Why this is asked A candidate who has only ever generated a spec from annotations tends to describe it as "whatever Swagger produces". A candidate who edits specs by hand can say where a new endpoint goes, why the schema lives under `components.schemas`, and why moving a host into `servers` is a one-line change rather than a search-and-replace across the file.

  • If a document has no servers key at all, what is the effective server?
    A single Server Object with the url `/`. Requests are interpreted as relative to wherever the document is hosted, which is why self-hosted specs behind a gateway often omit `servers` entirely and still resolve correctly.
  • Does putting a schema under components.schemas expose anything to clients?
    No. `components` is a registry of definitions with no effect on its own; a schema only takes part in the contract once something under `paths` (or `webhooks` in 3.1) reaches it through a `$ref`. Unreferenced components are dead weight that linters usually flag.
  • What is the difference between info.version and the openapi field?
    `openapi` is the version of the OpenAPI specification the document conforms to, for example `3.1.0`. `info.version` is the version of the API being described, for example `2026-04` or `1.4.0`. They change for entirely unrelated reasons.

saying these in an interview costs you the question

  • Says openapi field holds the API's version number
  • Thinks components.schemas publishes endpoints by itself
  • Cannot name the root keys without a generator
  • Believes servers is required in every document
  • Confuses tags declaration with path grouping semantics

context

open as a page

In OpenAPI 3.x, what does an operation object contain and what is operationId for?

level: middleimportance: must knowfreq 62%

basics

~20 s

An OpenAPI operation object describes one HTTP method on one path: tags, summary, description, operationId, parameters, requestBody, responses, callbacks, deprecated, security and servers. operationId is a document-unique name that tooling uses to identify the operation, typically as the generated method name.

open as a page

In OpenAPI 3.x, how are an operation's responses keyed, and what does default mean?

level: middleimportance: should knowfreq 52%

basics

~20 s

An OpenAPI responses object maps quoted HTTP status codes such as '200', uppercase range wildcards such as '4XX', and the literal key default to Response Objects. default covers any status not matched explicitly. Every Response Object requires a description.

open as a page

What changed structurally from Swagger 2.0 to OpenAPI 3.0 in a spec document?

level: middleimportance: should knowfreq 45%

basics

~20 s

OpenAPI 3.0 replaced Swagger 2.0's host, basePath and schemes with a servers array, turned body and formData parameters into requestBody, replaced document-level consumes and produces with per-operation content maps, and moved definitions, parameters, responses and securityDefinitions under components.

open as a page

Your team moves an OpenAPI 3.0 document to 3.1 — what changes at the document level?

level: seniorimportance: should knowfreq 34%

basics

~20 s

OpenAPI 3.1 adds the root keys webhooks and jsonSchemaDialect, makes paths optional so a document may describe only webhooks or components, adds a pathItems bucket to components, adds info.summary and an SPDX license.identifier, and aligns Schema Objects with JSON Schema 2020-12.

open as a page