Open mmautner opened 10 years ago
Would it help to allow the user to add decorator functions to the view methods (by extending the list stored at views.API.decorators
)? Those decorators are applied at each request.
Why would a server need caching for the responses of PUT, POST and DELETE? Caching of GET response is my concern.
According to StackOverflow, if the HTTP POST request includes the appropriate headers, then the application running on the server may cache an HTTP response, whatever that may mean. I think it should be theoretically allowed even if not used often in practice. Plus it may be easier to allow a decorator on top of all methods, rather than on just one.
Perhaps Flask-Restless should provide some default caching, checking for the appropriate HTTP headers?
Given that I could select which HTTP method to do caching, I would support your idea of one decorator for four methods.
Internet Explorer had default caching, which took me some time to figure it out. So, personally I wouldn't want default caching unless I would like to have it.
In the example, I didn't see cache duration and cache storage. Hopefully, it's possible to use Flask-Cache.
...
model_route = '{0}api0.{0}api'.format(manager.collection_name(model))
...
I was investigating issue #99 about how to cache API results and realized that the Flask-Restless pre-/post-processors are not the way to go as they cannot return a response in lieu of what the class-based view functions return.
What is the best way to then go about decorating the views that get added to the app object by the Flask-Restless blueprint?
Here's a go I had it, but am curious whether there's a better/more harmonious way to do it: