Allow using RFC 6570 URL templates to specify parameter serialization settings

[sm-Fifteen]

Is your feature request related to a problem? Please describe.
OpenAPI supports various parameter serialization settings (namely style, explode and allowReserved) which enable API designers to adapt the formatting of their routes, query parameters, headers, etc.

Describe the solution you'd like
I'm not entirely sure whether FastAPI supports using these as parameter keywords (such as Query(..., style='pipeDelimited')), but following the discussion on issue #230, I've been wondering if it wouldn't be a better idea to let users specify serialization parameters as part of their route URL template as specified by RFC 6570. The syntax is fairly unobtrusive and covers most (though not all, the style values for pipeDelimited and spaceDelimited are absent from the RFC) serialization settings covered by OpenAPI.

This would allow path parameters to support more complex formatting styles (the matrix and label styles are allowed for path variables in OpenAPI) and could solve a number of ergonomic problems regarding query parameters as well (such as having to explicitely use the Query constructor for Lists to avoid the default behavior), since they could now be optionally specified in the route (@app.get('/my/api{?myList*}')).

Describe alternatives you've considered
The URL templates could also stay the way they are and the style be delegated to Param values, although having to fall back on them makes function signatures look extremely verbose.

[tiangolo]

I would prefer not to add custom logic that requires a special syntax inside of strings, when it can be handled in other ways.

Special syntax in strings can't be checked for errors by editors, there's no completion, require complex custom logic, etc.

[sm-Fifteen]

Yeah, I'll admit that it wouldn't be a perfect solution. Ever though OpenAPI's serialisation options are based on that RFC, it adds a few options that would have to use a custom syntax, and the RFC seems more geared towards URL generation than URL parsing anyway, so a few of the template expansion styles don't look like they'd actually combine together.

It seemed like a concise way of dealing with a number of issues with the current templating system, but I understand your recluance, especially regarding the use of characters that only make sense in the context of that spec.

[sm-Fifteen]

See the broader issue discussion #283/#8322, and currently open issue on deepObject query parameter format #3163.

Tiangolo mentions Pydantic V2 as a big milestone he's waiting on to rework the integration in several places in the other issue, so we'll see how that goes. Latest estimates for Pydantic V2 say we should see it by the end of March.

[tiangolo]

I'll close this now, but feel free to add more comments or new issues 😄

[github-actions[bot]]

Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs.