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.
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(assumingapplication/x-www-form-urlencoded). However, with an object field:{ "name": "foo", "value": { "bar": "baz", "qux": 42 } }We'd get
bar=baz&qux=42and lose the fieldname. 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 getfoo[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.