11

我一直在阅读有关版本 REST API 的所有方法。在几乎所有的实现中，控制器和视图都是版本化的，但模型不是。

以 rails 为例，控制器组织为：

# app/controllers/api/v1/events_controller.rb
class Api::V1::EventsController < Api::ApiController

end

相应的视图也放在不同的版本目录中。为什么我们不对模型进行版本化？是因为我们希望我们的模型（底层数据库模式）不会随着 API 的发展而改变吗？当我重命名数据库中的列名并且需要一个新模型来解决这个问题时会发生什么？

4

2 回答 2

15

模型是应用程序内部的一部分，而不是其公共 API。版本控制的关键是输入/输出不偏离。

在数据库中维护不同版本的数据——例如，属于不同版本的 API 的数据不是特别吸引人或实用的。

因此，您将使用适配器/序列化器来调整输入/输出以适应 API 的特定版本，而内部则以当前版本运行。

假设您匆忙发布了 API v 1：

GET api/v1/users/:id
  username (String)
  first_name (String)
  lastname (String)

发布后，您意识到命名不一致。因此，您将创建一个重命名lastname为last_name.

因此 API 版本 2 将具有以下签名：

GET api/v2/users/:id
  username (String)
  first_name (String)
  last_name (String)

但这应该会破坏对 的测试，API v1因为响应不再包含lastname.

因此，要修复它，我们将创建如下内容：

class Api::V1::UserSerializer < ActiveModel::Serializer
  attributes :username, :first_name, :lastname

  def lastname
    object.last_name
  end
end
于 2015-12-03T21:09:52.400 回答
4

为什么我们不对模型进行版本化？

模型通常与数据库模式紧密结合。通常，数据库是所有版本的 API 共享的规范数据存储，因此对模型进行版本控制没有多大意义。

另外，在 Rails 应用程序中，大部分业务逻辑通常驻留在模型中。版本控制模型将需要复制逻辑或添加另一个抽象层，这会引入维护开销。

是因为我们希望我们的模型（底层数据库模式）不会随着 API 的发展而改变吗？

不会。数据库架构可以而且确实经常更改。

当我重命名数据库中的列名并且需要一个新模型来解决这个问题时会发生什么？

您不会引入模型来解释架构更改。您调整现有模型以适应更改，然后修改先前 API 的实现，以便先前版本的客户端继续以与之前预期相同的格式获得响应。

由于您的业务实体（模型）到 API 响应的这种映射发生在控制器（或序列化程序或 json 模板 - 取决于您的首选实现）中 - 您的应用程序的这些部分必须进行修改以确保向后兼容性。

于 2015-12-03T21:27:42.030 回答