当前位置:  开发笔记 > 编程语言 > 正文

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

如何解决《RESTAPI版本控制-为什么版本不是模型》经验,为你挑选了1个好方法。

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

为了给出rails示例,控制器组织为:

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

end

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



1> max..:

模型是应用程序内部的一部分,而不是其公共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

推荐阅读
凹凸曼00威威_694
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有