You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using httdomain on a tornado project with "auto tornado" to generate API documentation and it's great. A nice-to-have feature is the ability to specify a custom filter function to the autotornado directive to allow for greater dynamic control over which API routes are published vs. not. A few use cases include:
Private/internal APIs endpoints that shouldn't be accessed by end-users
"Unstable" APIs that are intended for eventual public consumption but should remain undocumented in official docs until the API has stabilized
I'd propose a "filter-endpoints" parameter to the auto tornado directive. It would take a tornado rule target (Rule or URLSpec) or a method/function target of such rule and return True to exclude the item (the item is filtered) and False to include it (the item is not filtered).
For instance, a filter function that excludes classes and methods which have "PRIVATE API" in the docstring:
def doctoring_private_filter(obj):
return "PRIVATE API" in obj.__doc__
I'm using httdomain on a tornado project with "auto tornado" to generate API documentation and it's great. A nice-to-have feature is the ability to specify a custom filter function to the autotornado directive to allow for greater dynamic control over which API routes are published vs. not. A few use cases include:
I'd propose a "filter-endpoints" parameter to the auto tornado directive. It would take a tornado rule target (Rule or URLSpec) or a method/function target of such rule and return True to exclude the item (the item is filtered) and False to include it (the item is not filtered).
For instance, a filter function that excludes classes and methods which have "PRIVATE API" in the docstring:
And would be setup as:
The text was updated successfully, but these errors were encountered: