REST API版本控制 - 为什么版本不是模型

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 模板 - 取决于您的首选实现）中 - 您的应用程序的这些部分必须进行修改以确保向后兼容性。