6

我目前正在为新网站设计版本化 API。我了解如何命名路由，但我坚持在模型中实现版本化方法的最佳方式。

下面的代码示例使用的是 rails 框架，但大多数 web 框架之间的事情原理应该是一致的。

路线目前看起来像：

MyApp::Application.routes.draw do
  namespace :api do
    namespace :v1 do
      resources :products, :only => [:index, :show]
    end
  end
end

和控制器：

class Api::V1::ProductsController < V1Controller
  respond_to :json, :xml

  def index
    respond_with @products = Product.scoped
  end

  def show
    respond_with @product = Product.find(params[:id])
  end
end

所以很明显，我们只是在这里公开了 Product 上可用的属性，如果你只需要一个版本的 API，这个解决方案就很好用。当您想要发布 V2 并且 V2 需要重新实现产品名称的显示方式时会发生什么（同时保持与 V1 的向后兼容性 - 至少在短期内）？

据我所知，你有几个选择......

  1. 立即放弃对 V1 的支持并处理后果（可能的最坏解决方案）
  2. 您开始覆盖 to_[format] 方法（我很确定您使用 as_[format] 执行此操作，但这是题外话）以包含一个新属性...-name_2这似乎同样愚蠢
  3. 实现某种代理类，它只负责公开我们所追求的方法
  4. 让视图处理创建某种散列，版本化控制器并调用to[format]...

三个和四个是我真正认为有意义的唯一一个......三个看起来像：

# model
class Api::V1::Product < Struct.new(:product)
  def to_json
    attributes.to_json
  end

  def to_xml
    attributes.to_xml
  end

private
  def attributes
    {:name => product.name} # add all the attributes you want to expose
  end
end

# Controller
class Api::V1::ProductsController < V1Controller
  respond_to :json, :xml

  def show
    respond_with @product = Api::V1::Product.new(Product.find(params[:id]))
  end
end

其他人过去做了什么？

4

2 回答 2

6

而不是一个应用程序提供 V1 和 V2 和 V... 您为每个版本部署一个应用程序。一个应用程序将回答 api.domain.com/v1，然后另一个应用程序将回答 api.domain.com/v2，依此类推。

这就是面向服务的应用程序的最佳组织方式，每个服务应该是隔离的，独立的部署。

从单个应用程序为所有版本提供服务违背了面向服务设计的目的，因为每次您对一项服务进行更改时，您都需要对所有版本进行测试和部署。

于 2011-07-23T00:46:51.483 回答
-1

如果您计划创建不同的版本，我认为您可能会过度设计您的 API。只要您以后不再删除 URL 和属性，旧客户端就可以继续使用您的 API。当 API 解决错误或怪癖时，只需使用 v1、v2 等作为隔离客户端的方法。

如果您正在更改原始 API 可以支持的基础架构，那么我同意如果您计划支持旧客户端，您将需要为旧平台创建代理。对于新系统，我将按照@Nerian 的建议创建一个全新的端点服务器。

于 2012-05-13T20:35:48.047 回答