Repository navigation
Customize cache key generation #30
Description
| Q | A |
|---|---|
| Bug? | no |
| New Feature? | yes |
| Version | 1.2 |
Actual Behavior
The cache key is currently generated based on the following details:
- hash algo
- request method
- URI
- request body
Expected Behavior
One should be able to customize this behaviour.
Example: Separate cache entry per authorization header.
Possible Solutions
Introduce a CacheKeyGenerator interface which would receive the request as a parameter.
It should be an optional parameter of the plugin, falling back to the current implementation.
Activity
dbu commentedon Mar 21, 2017
👍
I think the key generator should also have the possibility to say a request is not cacheable. Maybe by throwing a specific exception, as that is nicer than returning
nullto indicate we don't want the request to be cached.Nyholm commentedon Mar 21, 2017
👍
Maybe... or we put that functionality in another class.
dbu commentedon Mar 21, 2017
sagikazarmark commentedon Mar 21, 2017
I agree with @Nyholm, it's a separate responsibility. The CacheKeyGenerator can throw an exception though which can result in cacheability to be impossible, but that decision needs to be made elsewhere.
Actually I forsee that we are going to move the entire caching stuff to the message package and just wrap it in the plugin. Not sure if it makes sense, but we are putting tons of effort into it, would be nice to see if the caching logic can be used elsewhere or not.