Search code examples
flaskeve

in python-eve, how can I honor "size" query parameter as an alias for "max_results"


I'm developing an API using python-eve and loving it. So far I've been able to do everything using various hooks available. However, now I want to support "size" query parameter as an alias for "max_results" (for backward compatibility reasons, if that matters).

I tried to create on_pre_GET hook but found out that request.args is unmodifiable

def pre_get_api_sugar(resource, request, lookup):
    """Event that adds syntactic sugar to the API calls.
    """

    # Support "size" as alias for "max_results"
    args = request.args
    if 'max_results' not in args and 'size' in args:
        args['max_results'] = args['size']


app.on_pre_GET += pre_get_api_sugar

This gives TypeError: 'ImmutableMultiDict' objects are immutable

It seems like manipulating query parameters to customize the API should be something doable if not easy. So far I'm not seeing a way to do that. Is there a Flask facility for this that I should use? What am I missing?

Thanks!


Solution

  • UPDATE

    Customizable query parameters have been added to Eve 0.5-dev, so now you can set

    QUERY_MAX_RESULTS = 'size'
    

    to override the default setting (which still happens to be max_results). Similar settings have been added for other query params like where, sort, projection, page, embedded.

    ORIGINAL ANSWER As you say Flask (and Eve) use an immutable object for storing request args. However, you could choose to use parameter_storage_class to change the default class:

    the class to use for args and form. The default is an ImmutableMultiDict which supports multiple
    values per key. alternatively it makes sense to use an ImmutableOrderedMultiDict which preserves
    order or a ImmutableDict which is the fastest but only remembers the last key. It is also possible
    to use mutable structures, **but this is not recommended**.
    

    Emphasis on last sentence is mine.

    This being said, it is probably a good idea to allow API maintainers to customise the query dialect of their APIs, so I think I'm going add new settings (somethink like QUERY_MAX_RESULTS) which default to current values but can be easily changed. I will update the answer when it's done (you might want to open a ticket, so it doesn't get lost).