-
Notifications
You must be signed in to change notification settings - Fork 265
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
Query serializer support #10
Comments
that looks interesting. i need to refactor the parameter section. the old code did some funky stuff that needs changing. i'll try to incorporate this with it. |
Any updates? Maybe I can help you somehow? |
sry too keep you waiting. i had to do some heavy structural changes. this will be the next feature. 😄 |
It seems that this is the last feature that remains to be implemented. Otherwise, it looks like it’s ready :-) |
So OpenAPI3 has multiple ways achieving this. could you post an example query for that? option 1: exploding the serializer into seperate fields, as if OpenApiParameter was used multiple times and option 2 has even more sub-options for formatting and serialization. i think this is one of the more complicated sections of the spec. |
If I understand you correctly, then you need to give an example of how this should look? One example class PublicCommentsRequest(Serializer):
include = CharField(required=False)
order_by = CharField(required=False)
order_direction = ChoiceField(choices=['ASC', 'DESC'], required=False)
start_datetime = DateTimeField(required=False)
end_datetime = DateTimeField(required=False)
@extend_schema(
parameters=[PublicCommentsRequest,OpenApiParameter('expiration_date', OpenApiTypes.DATETIME, description='time the object will expire at')],
responses={201: None},
) |
unfortunately, there is more info required to build the schema here. i suppose you refer to option1. i was asking about how the actual query will look like, that is how this is supposed to look in the query section of the HTTP request. https://swagger.io/docs/specification/serialization/#query
option2 has even more variations. |
Wow, I didn't think there were so many different options! Perhaps then it will be possible to expand it somehow. It’s better to make a simple option, and then gradually complicate it, if necessary |
I think that option 1 is the most used by far in REST APIs |
@tsouvarev yes i think so too. |
@MissiaL: i had a hard look and decided to do it as you suggested.
i think that should do it for now. |
Thanks! It works great! |
In my current project i i find use query_serializer. Like this
It looks like this
Could you add similar functionality?
I could use
extra_parameters
, but it looks complicatedThanks
The text was updated successfully, but these errors were encountered: