用于缓存外部API的API设计

时间:2012-07-18 18:53:54

标签: ruby api caching

我已经构建了一个轻量级的Ruby代码来包装外部API:

api = ExternalAPI.new
api.expensive_operation(object)

工作正常。但是,由于API很昂贵,我不想在必要时调用它。这就是为什么我要创建一个用本地缓存包装API调用的更高级API。我不希望应用程序不必担心有关如何缓存API的详细信息。 (缓存可以通过内存,磁盘,abaci,甚至pigeons完成 - 这不是应用程序的关注点。)

以下是我目前正在考虑的事项:

wrapper = ExternalAPIWrapper.new
wrapper.expensive_operation(object)

我不喜欢名字ExternalAPIWrapper。它是通用的,不传达包装器的目的。特别是,它并不表示它首先检查本地缓存,只在必要时才会访问低级API。

我正在寻找能够改善这一起点的答案。以下是我正在寻找的一些事情:

  1. 高级班级的更好名称
  2. 更好的样式API
  3. 可能有用的设计模式
  4. (也许是一个长篇...)一个包装和缓存API调用的Ruby gem

3 个答案:

答案 0 :(得分:3)

对于#1,我想到的名字是CachedExternalAPI :)不确定“更好的样式API”是什么意思。

至于#3/4:我不知道RubyGem是做这种缓存的事情,但是我以“元编程”方式实现缓存的API,自动为缓存的API调用生成方法,例如

class CachedExternalAPI
  @cache = { }

  class << self

    [:foo, :bar, :baz].each do |m|
      define_method m do
        return (puts "Totally cached!"; @cache[m]) if not @cache[m].nil?
        puts "Not cached :("
        @cache[m] = 42
      end
    end

  end
end

CachedExternalAPI.foo()
CachedExternalAPI.foo()

CachedExternalAPI.bar()
CachedExternalAPI.bar()

哪个会产生

  

未缓存:(
  完全缓存!
  没有缓存:(
  完全缓存!

这当然假设所有API调用的缓存机制都是相同的。但是,如果您的API可以通过这种方式缓存,则可以将缓存的API包装器保持为DRY。

答案 1 :(得分:2)

Rob,我的一位朋友,发现了APICache

  

APICache(又名api_cache)

     

APICache允许使用强大的缓存层轻松包装任何API客户端库。它支持缓存(显然),提供陈旧数据和限制API调用的数量。如果你想做的就是缓存一个麻烦的网址,它也有一个方便的语法。

APICache支持多种缓存策略,包括:

  • 简单的内存缓存
  • 通过Moneta的各种后端,“键值存储的统一接口”
  • Memcached via Dalli,以Dalí的Persistence of Memory命名

答案 2 :(得分:0)

确切地知道你想要什么的细节太少但是我想到了一个桥接模式,因为你在考虑改变你的缓存后端时实际上是在试图解耦你的抽象和实现。