-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot specify encoding style for object and array elements #283
Comments
This is currently not supported. FastAPI generates valid OpenAPI schemas that cover a very wide range of APIs, and a wide amount of what is described in the spec, but it doesn't necessarily have a way to specify absolutely everything described in the OpenAPI spec, still, the API schemas generated are OpenAPI valid. I think this is the same you wrote in #268 , right? |
I realized afterwards that this was trying to push a solution (and one with a good number of pitfalls, at that) to a problem that hadn't been clearly stated yet, hence why I decided to open this second issue as a bug (now a question) instead of a feature request. This issue was meant to somewhat subsume or replace #268.
Yeah, I've been looking into the whole FastAPI stack and code these past few weeks, and it's clear now that this should probably be raised as a Pydantic issue before reporting it here. |
I'll close this issue now as I think this would be more or less a corner case, with quite some extra complexity. But if you still need to implement some sophisticate extra features like these for your use case, it's now possible to subclass and override the https://fastapi.tiangolo.com/tutorial/custom-request-and-route/ |
@tiangolo: I understand, it really is a very niche corner case. I was just attempting to use FastAPI to replicate existing APIs, and that came up as an unsupported feature that could have proved useful. If you're designing your own API from scratch, though, I would agree that the usefulness of this would be pretty limited. I'll be sure to look into custom routers and Query parameters. Thank you. |
We are migrating to FastAPI and has a requirement of keeping compatibility with current API docs and actual API, where we are receiving comma-delimited string and have the server auto-explode into string list. It would be nice if FastAPI's way of declaring Query has an extension for that. At the moment, we would have to do validation on |
@lephuongbg: pydantic/pydantic#1848 adds something akin to what you're describing to Pydantic, but support would need to be added to FastAPI for it to be properly exposed in the generated API documentation, I believe. @tiangolo: As the author of the PR I mentioned, do you think FastAPI could benefit from an integration with these as far as parameter typing is concerned? |
Right now Pydantic v2 is about to be released, that will include a bunch of features, and I want to update several things related to that here in FastAPI. Not sure what would be the effort and complexity involved in supporting this, but maybe we can check it again after that, maybe there's a way to achieve it, but I'll have to do the other things first.
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Describe the bug
OpenAPI defines a number of encoding styles for complex types like arrays and objects, and specifically reccomends using them for things like form data encoding. While the underlying OpenAPI models for parameters appear to support this, using them does not affect the resulting OpenAPI definition.
This also prevents more complex object encodings from being used for query parameters, which some API standards may require.
Expected behavior
All parameter types provided by FastAPI should support parameter encoding and schema encoding where applicable, as specified by the OpenAPI specification. If consistency is to be taken into account, adding keywords parameter for
style
,explode
andallowReserved
would probably be ideal. An alternative syntax for path variables and possibly query variables has been proposed before (see #268), but concerns have already been raised about the ergonomics of this solution, not to mention that it would not cover the other parameter types and having both solutions could prove to be a source of bugs and confusion for everyone.Environment:
The text was updated successfully, but these errors were encountered: