# Request Parameters in OpenAPI best practices

# Parameters in OpenAPI

Parameters are used to describe inputs to an operation. Parameters can be defined at the path or operation level and are merged with any duplicates at the operation level, overriding any defined at the path level.

Each parameter needs to be uniquely identified by a combination of its `name` and `in` fields in an [operation](/openapi/paths/operations).

A parameter in the list can either be a [Parameter Object](/openapi/paths/parameters#parameter-object) or a [Reference](/openapi/references) to a [Parameter Object](/openapi/paths/parameters#parameter-object) defined in the [Components Object](/openapi/components) under the `parameters` field.

Parameters can represent a number of different input types, including:

- Path Parameters
- Query Parameters
- Headers
- Cookies

Example:

```yaml
paths:
  /drinks/{type}:
    parameters:
      - name: type
        in: path
        description: The type of drink to filter by.
        required: true
        schema:
          $ref: "#/components/schemas/DrinkType"
      - name: Cache-Control
        in: header
        description: The cache control header.
        required: false
        schema:
          type: string
          enum:
            - no-cache
            - no-store
            - must-revalidate
            - max-age=0
            - max-age=3600
            - max-age=86400
            - max-age=604800
            - max-age=2592000
            - max-age=31536000
    get:
      operationId: listDrinks
      summary: Get a list of drinks.
      description: Get a list of drinks, if authenticated this will include stock levels and product codes otherwise it will only include public information.
      security:
        - {}
      tags:
        - drinks
      parameters:
        - name: limit
          in: query
          description: The maximum number of drinks to return.
          required: false
          schema:
            type: integer
            minimum: 1
            maximum: 100
        - name: filter
          in: query
          description: Advanced filter criteria as a JSON object.
          required: false
          content:
            application/json:
              schema:
                type: object
                properties:
                  productCode:
                    type: string
                  inStock:
                    type: boolean
      responses:
        "200":
          description: A list of drinks.
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Drink"
```

## Parameter Object

The order of fields above is recommended for defining fields in the document.

## Parameter Serialization

OpenAPI provides two mutually exclusive ways to describe how parameter values are serialized: using `schema` with `style` and `explode`, or using `content`. You must use one or the other, but not both.

### Schema with Style and Explode (Recommended for Most Cases)

The `schema` approach is the standard way to define parameters and is suitable for most scenarios. It works well for primitive values, arrays, and simple objects that can be serialized into a string.

With this approach, serialization is controlled by:
- **`style`**: Defines the serialization format (e.g., `form`, `simple`, `matrix`, `label`)
- **`explode`**: Controls whether arrays and objects are expanded into separate parameters

Example of array serialization using `schema`:

```yaml
parameters:
  - name: colors
    in: query
    schema:
      type: array
      items:
        type: string
    style: form
    explode: false
```

This serializes as: `?colors=blue,black,brown`

For detailed serialization rules for each parameter type, see the [path](/openapi/requests/parameters/path-parameters), [header](/openapi/requests/parameters/header-parameters), [query](/openapi/requests/parameters/query-parameters), and [cookie](/openapi/requests/parameters/cookie-parameters) parameter documentation.

### Content (For Complex Serialization)

The `content` approach is designed for complex serialization scenarios that cannot be handled by `style` and `explode`. This is particularly useful when you need to send structured data using a specific media type serialization, such as JSON.

Use `content` when you need to:
- Send complex nested objects that require JSON serialization
- Use a specific media type format for the parameter value
- Handle serialization that goes beyond what `style` and `explode` support

Example of JSON-serialized object in a query parameter:

```yaml
parameters:
  - name: filter
    in: query
    description: Filter criteria as a JSON object
    required: false
    content:
      application/json:
        schema:
          type: object
          properties:
            type:
              type: string
              example: t-shirt
            color:
              type: string
              example: blue
            priceRange:
              type: object
              properties:
                min:
                  type: number
                max:
                  type: number
```

This parameter would be sent as a JSON string in the URL:

```
?filter={"type":"t-shirt","color":"blue","priceRange":{"min":10,"max":50}}
```

The `content` field maps media types to schemas, allowing you to specify exactly how the parameter should be serialized and deserialized. While `application/json` is common for complex query parameters, you can use any media type that makes sense for your API.

**Important**: You cannot use `style` and `explode` when using `content`. Choose the approach that best fits your serialization needs.