How does content negotiation work in OpenAPI, using the content field?

OpenAPI 3.0's content field lets a single request body or response describe different schemas for different media types, mirroring how real HTTP content negotiation (via Accept and Content-Type headers) allows the same logical resource to be represented differently depending on what the client requests.

responses:
  '200':
    content:
      application/json:
        schema:
          $ref: '#/components/schemas/User'
      application/xml:
        schema:
          $ref: '#/components/schemas/UserXml'

Each key under content is a media type, and its value defines the schema (and optionally examples) specific to that representation, which is a direct improvement over Swagger 2.0's global produces/consumes arrays that applied one assumed content type across an entire operation without letting different media types have genuinely different schemas.

This is most relevant for APIs that genuinely support multiple response formats for the same logical resource — JSON and XML both being valid representations of the same user object, for instance — or for describing versioned custom media types (like application/vnd.example.v2+json) where the schema itself legitimately differs between versions even though the URL and HTTP method stay the same.