我已经阅读了版本RESTAPI的所有方法。在几乎所有的实现中，控制器和视图都有版本控制，但模型没有。
举个轨道的例子，控制器被组织为：
# app/controllers/api/v1/events_controller.rb
class Api::V1::EventsController < Api::ApiController
end
相应的视图也放在不同版本的目录中。为什么我们不给模型换个版本？这是因为我们期望我们的模型（底层数据库模式）不会随着API的发展而改变吗？当我重命名数据库中的列名并需要一个新模型来解释时，会发生什么？
模型是应用程序内部的一部分，而不是其公共API。当版本控制时，关键是输入/输出不会偏离。
在数据库中维护不同版本的数据（例如，属于API不同版本的数据库数据）并不是特别有吸引力或实用。
因此，您将使用适配器/串行器将输入/输出调整为API的特定版本，而内部运行在当前版本。
比方说你已经发布了一个API版本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
为什么我们不给模型换个版本？
模型通常与数据库模式紧密一致。通常，数据库是由所有版本的API共享的规范数据存储，因此对模型进行版本化没有多大意义。
此外，在Rails应用程序中，构建逻辑的大部分通常驻留在模型中。版本控制模型将需要复制逻辑或添加另一个抽象层，这会引入维护开销。
这是因为我们期望我们的模型（底层数据库模式）不会随着API的发展而改变吗？
没有。数据库模式可以而且确实经常更改。
当我重命名数据库中的列名并需要一个新模型来解释时，会发生什么？
您没有引入模型来解释架构更改。您调整现有模型以适应更改，然后修改以前API的实现，以便以前版本的客户端继续以与以前预期的格式获得响应。
由于构建实体（模型）到API响应的映射发生在控制器（或序列化器或json模板中，具体取决于您的首选实现）中，因此必须修改应用程序的这些部分以确保向后兼容性。