Question

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

为了给出rails示例，控制器组织为：

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

end

同样的视图也放在不同版本的目录中。为什么我们没有版型号？是因为我们希望我们的模型（底层数据库模式）不随着API的发展而改变吗？当我在数据库中重命名列名并需要新模型来解释它时会发生什么？

Answer 1

模型是应用程序内部的一部分，而不是其公共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 v 1，因此应该打破lastname的测试。

所以要解决它，我们会创建类似的东西：

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

  def lastname
    object.last_name
  end
end

Answer 2

为什么我们不打算购买模型？

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

另外，在Rails应用程序中，通常大量的商务逻辑都存在于模型中。版本控制模型需要复制逻辑或添加另一个抽象层，这会引入维护开销。

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

没有。数据库模式可以并且确实经常发生变化。

当我在数据库中重命名列名并需要新模型来解释时，会发生什么？

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

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