[SirtusKottus]

Added custom query params for action function in Client ( up to build request in http) to allow using custom functionality in query params ( for example using query params which are not visible in schema or custom filtering )

[SirtusKottus]

Sometimes its useful to have query_params which are not validated with schema because even good documentation not always generates schema with all available query params. For example generic filtering for api

[SirtusKottus]

Hey is any one going to approve this pull requests ?? :)

[dimgarof]

Hey, this should be cool to have!

[SirtusKottus]

Next thing which this will fix is using "ordering" is not visible in schema. DRF documantation about setting ordering
We are using django-url-filter in our project. So to add ordering i'm using this solution miki725/django-url-filter#10 and its not possible to use it because:
Error: Uncaught (in promise): ParameterError: Unknown parameter: "ordering"

EDIT: i have tested that with my version and it works.
EDIT2: django-url-filter works too.

[SirtusKottus]

@tomchristie could you look at this ?

[lovelydinosaur]

For now I'd like to see folks approach this from the other side (ie. fix up the schema, so you don't need to include "extra" unknown query parameters in the client)

[mmankows]

@tomchristie Solution you're suggesting would be an overkill in many real-life cases.
Consider filter backends which allow nesting model fields:
?primarykeyfield__releatedmodelfield__gte=10
This attitude makes django pluggable desing even harder to implement - every middleware class using request parameters would cause problems with schema. Every custom schema modification would cause unnecessary dependencies to maintain - some of them non-trivial (filtering example).
In my opinion the real strength of Coreapi schema is a minimal effort needed to connect back and front in a elegant way.

Either CoreAPI schema format schould be changed (to allow adding global parameters like pagination and filtering on a top level) or less strict client code issued.
Current OpenAPI format breaks DRY principle hard if you'd have to repeat global paremeters used by filtering/ordering/pagination middlewares in each view.

[SirtusKottus]

@tomchristie we started doing this in your way which was difficult because this part how to fix schema is poorly documented. After couple hours of searching I couldn't find solution to add page and page size to schema in custom @list_route.
After I found solution i could already help some one: https://stackoverflow.com/questions/47041288/how-to-pass-a-custom-schema-to-a-drf-detail-route/47077580#47077580
After that we will still have problem with filtering which includes multiple nesting: https://github.com/miki725/django-url-filter . Maintaining schema with this type of filtering will be a horror or at least useless.