【问题标题】:API: Is it better to have a slower, conventient API implementation or a faster, more complex one?API:使用更慢、更方便的 API 实现还是更快、更复杂的实现更好?
【发布时间】:2011-03-05 17:36:56
【问题描述】:

我正在使用 Ruby on Rails 3,并且正在为我的应用程序开发 API。

我有一个 Web 客户端应用程序向 Web 服务器应用程序发出 HTTP 请求。然而,Web 应用程序在控制器中处理传入请求并做出如下响应:

respond_to do |format|
  format.html {redirect_to @account}
  ...
  format.json {
    render :json => @account.to_json, :status => 200
  }
  format.xml {
    render :xml => @account.to_xml, :status => 200
  }
end

目前我不使用 Rack 中间件,因为使用 respond_to 响应非常“方便”,并且您无需在应用程序中更改控制器以外的任何其他内容。无论如何,我知道使用中间件比上述方法响应更快,但我应该为每个 HTTP 请求实现响应,也许拦截它们的 URI。

你有什么建议?更好的是“方便”和“慢”(如上面的代码)还是“复杂”和“最快”?

【问题讨论】:

  • 只有一个答案是正确的。对于小型站点,缓慢但方便的代码可能就足够了。对于处理大量流量的大型站点,可能值得以牺牲复杂性为代价来提高性能。一种简单的方法是估算实施更快方法所需的时间,以及站点服务器的成本(包括管理、电力等)。尽量减少长期成本。
  • 我要补充一点,TDD 的理念是:编写足够的代码以使您的测试通过。

标签: ruby-on-rails ruby api ruby-on-rails-3 middleware


【解决方案1】:

Premature optimization is the root of all evil。如果使用您喜欢的设计,代码的速度足以满足您的目的,请继续使用它。如果您发现它不够快,那么您可以查看加快速度的选项。

【讨论】:

  • +1 我更喜欢 97% 的报价,但是 ... :) 还需要注意 1) 实际 问题可能事先不知道(a可能需要不同/“复杂”的设计,但它可能与初始方法不同,例如“简单”可以用作原型)2)使用应用程序有更好的机会生成$$$ 然后可以用来使所说的应用程序更好
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-09-01
  • 2010-10-11
  • 1970-01-01
相关资源
最近更新 更多