Make api-key data more generic in order to attach more info to it #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a NON-BREAKING change. The old API still works, but the new one is executed first. If the API-KEY hasn't been defined in the new format ( as JSON ), it would read the old format ( individual Redis fields ).
In the old format all the fields associated with an API-KEY were stored using
HMSET
i.e.In the new format we're using the same Redis Key but we're storing the metadata into a new field called
metadata
, usingHSET
. This field stores a JSON string.Since both
HSET
andHMSET
are working on the same Redis Key the new implementation is additive and non breaking, as it simply adds a new field to the existing hash. IfHGET cachedkey:$key:$service_id metadata
returns the JSON, its value is used, else the API-KEY validator will try to do anHMGET
on the other fields.