Skip to content

Support Object Field Values #29

Description

@dillonredding

There is currently support for primitive, Date, and array field values, but I would consider support for object values. The main question is around serialization.

We might be able to borrow some ideas from how the OpenAPI spec handles different styles of parameter serialization. In the current implementation, we treat array values as an exploded form (style=form, explode=true). For example, this field:

{
  "name": "foo",
  "value": ["bar", 42]
}

Results in foo=bar&foo=42 (assuming application/x-www-form-urlencoded). However, with an object field:

{
  "name": "foo",
  "value": {
    "bar": "baz",
    "qux": 42
  }
}

We'd get bar=baz&qux=42 and lose the field name. This also runs the risk of unintentionally adding values to other fields with the same name. Not ideal.

So, the other viable options are unexploded form (style=form, explode=false) and deep object (style=deepObject, explode=true).

Treating objects as an unexploded form provides a concise serialization, but wouldn't be able to support nested objects (is that even something we need?). In the example above, we'd get foo=bar,baz,qux,42. On the other hand, the "deep object" approach effectively turns each entry into its own "parameter" and (theoretically) accounts for nested objects. In this case, we'd get foo[bar]=baz&foo[qux]=42.

I think the "deep object" strategy is more intuitive (at least with how arrays work) and gives us the most mileage. Perhaps we could follow up with a serialization option to select or even customize the object serialization strategy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions