{"action":"created","issue":{"url":"https://api.github.com/repos/Mashape/unirest-nodejs/issues/47","labels_url":"https://api.github.com/repos/Mashape/unirest-nodejs/issues/47/labels{/name}","comments_url":"https://api.github.com/repos/Mashape/unirest-nodejs/issues/47/comments","events_url":"https://api.github.com/repos/Mashape/unirest-nodejs/issues/47/events","html_url":"https://github.com/Mashape/unirest-nodejs/issues/47","id":57397779,"number":47,"title":"Cache support","user":{"login":"rprieto","id":189105,"avatar_url":"https://avatars.githubusercontent.com/u/189105?v=3","gravatar_id":"","url":"https://api.github.com/users/rprieto","html_url":"https://github.com/rprieto","followers_url":"https://api.github.com/users/rprieto/followers","following_url":"https://api.github.com/users/rprieto/following{/other_user}","gists_url":"https://api.github.com/users/rprieto/gists{/gist_id}","starred_url":"https://api.github.com/users/rprieto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rprieto/subscriptions","organizations_url":"https://api.github.com/users/rprieto/orgs","repos_url":"https://api.github.com/users/rprieto/repos","events_url":"https://api.github.com/users/rprieto/events{/privacy}","received_events_url":"https://api.github.com/users/rprieto/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Mashape/unirest-nodejs/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-02-12T00:05:34Z","updated_at":"2015-02-12T00:28:46Z","closed_at":null,"body":"Hi,\r\n\r\nIt would be great if `unirest` had support for a pluggable cache, just like the browser's local cache.\r\n\r\nI see many packages on `npm` that support specifying a `TTL` for each request - but I'd much rather take advantage of HTTP and actually read the response headers, and cache the response in memory for the appropriate amount of time (either `expire`, or `max-age - age`).\r\n\r\nIn a sense, this is very similar to a reverse-proxy. Do you think this could be part of `unirest`? Could it be some sort of plugin, where every request/response traverses the proxy and it decides whether to call the backend or returned cached data?\r\n\r\nIf the interface is nice & clean, I could imagine several implementation of that proxy, e.g. in memory, backed by Redis... Ideally they would each have smart limits depending on their constrains (memory limit, number of responses, LRU....).\r\n\r\nHappy to help implement this if you think it would be useful.\r\n"},"comment":{"url":"https://api.github.com/repos/Mashape/unirest-nodejs/issues/comments/73994920","html_url":"https://github.com/Mashape/unirest-nodejs/issues/47#issuecomment-73994920","issue_url":"https://api.github.com/repos/Mashape/unirest-nodejs/issues/47","id":73994920,"user":{"login":"Nijikokun","id":198276,"avatar_url":"https://avatars.githubusercontent.com/u/198276?v=3","gravatar_id":"","url":"https://api.github.com/users/Nijikokun","html_url":"https://github.com/Nijikokun","followers_url":"https://api.github.com/users/Nijikokun/followers","following_url":"https://api.github.com/users/Nijikokun/following{/other_user}","gists_url":"https://api.github.com/users/Nijikokun/gists{/gist_id}","starred_url":"https://api.github.com/users/Nijikokun/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Nijikokun/subscriptions","organizations_url":"https://api.github.com/users/Nijikokun/orgs","repos_url":"https://api.github.com/users/Nijikokun/repos","events_url":"https://api.github.com/users/Nijikokun/events{/privacy}","received_events_url":"https://api.github.com/users/Nijikokun/received_events","type":"User","site_admin":false},"created_at":"2015-02-12T00:28:46Z","updated_at":"2015-02-12T00:28:46Z","body":"> Thanks. Our current stop-gap solution is to call unirest, but wrap every call in a special handler to decide whether to make the call, cache the response, etc. Some built-in support would be amazing.\r\n\r\nThis is the correct way to do it, as it is a per case basis, not everyone will have the same requirements or situation as yours.\r\n\r\nHence why being a plugin would be a better solution for this situation."}}