怎么做 Web API 版本控制?

简评:这是 fly.io分享的一篇文章,讲了他们是怎么对自家 REST API 做版本控制的。另外还有很多其他的技术文章,个人感觉还不错,感兴趣的同学可以看一看。

API 设计是一个都快被说烂了的主题,已经有太多关于对 Web API 做版本控制很棒的文章了。比如:

但今天这里还是想分享一篇,希望看完能有所收获。: )

API 版本控制

虽然还没有一个绝对正确的方式来设计一个 API,但是有几个关键想法是许多开发者都同意的,一个优秀的 Web API 应该是:

  1. 能保证一致性和稳定性;
  2. 版本的向后兼容;
  3. RESTful。

为了能最好的实现这些理念,关于如何实现 API 的不同版本目前主要有三种做法:

在 URI 中标记版本

curl https://example.com/api/v2/lists/

通过解析 URI 中的版本号,客户端可以访问/v1//v2/等不同版本API。

在 Header 中标记版本

curl https://example.com/api/lists/3 \ 
-H 'Accept: application/vnd.example.v2+json'

直接不标记版本

curl https://example.com/api/lists/3

嗯,我们只有最新版本,赶紧去兼容吧。

不进行版本控制很有可能让 API 变得混乱,因此现在很少人会不做 API 版本控制了。而这里,我们选择同时在 URI 和 HTTP Header 中标记版本。下面让我们来看一个例子:

假设我们正在为我们的 MightyList 应用构建一个 API,可以通过这个 API 来请求一组数据:

curl https://mightyapp.com/api/v1/lists/3
...

{
  "listId": "3",
  "shopping": "Shoes, tie, umbrella, snorkel",
  "leisure": "Skiing, surfing, snorkeling ",
  "food": "bananas, peanut butter, spinach",
  "cost": "One hundred dollars"
}

我们先来看一个小的需求变化,在上面的例子中,cost

字段返回的是一个字符串。而现在我们的开发团队希望将其变成数值类型。

curl https://mightyapp.com/api/v1/lists/3
...

{
  "listId": "3",
  "shopping": "Shoes, tie, umbrella, snorkel",
  "leisure": "Skiing, surfing, snorkeling ",
  "food": "bananas, peanut butter, spinach",
  "cost": 100
}

这是一个很小的变动,但却会破坏我们 API 的向后兼容性。像这种比较小,但却会造成向后兼容性问题的变动,是应该进行版本号上的变动的。

还有一种就是比较重大的修改,比如:lists 变成了 superlists,又需要加入许多新的字段等等,这种大的升级基本都会破坏兼容性。这时通常做法都是将 URI 中的 /v1/变为/v2/

因此理论上只要是影响到向后兼容性的改动都应该反应在版本号上,提供 Change Log 给使用者。但如果不论变动大小都升级 URI 中的版本号,这又会造成过多的版本。

  • 为了保证我们应用状态的清晰,我们希望在 URI 中有一个代表产品版本的版本号。当产品有了较大,或根本性的改变时,URI 版本将会改变。比如,MightyList V1 使用/api/v1/,MightyList V2 使用/api/v2/

  • 而对于当前版本内的较小修改,我们使用自定义的 HTTP Header 来表示。作者使用的自定义 Header 名为 API-Version,值为 day-month-year 格式的日期。

这样我们就可以为 API 提供更新日志了,用户也可以通过配置版本日期来访问他们需要的 API 版本,就像这样:

当然 API 设计有许多不同的理念和做法,这里也只是其中一种,或许能对你有所启发。

英文原文:How to Version a Web API
旧文推荐:
Mozilla 、微软、谷歌、W3C、三星将一起构建 Web 的统一文档
用 WebGL 探索动画和交互技术(一个学习案例)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,179评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,229评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,032评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,533评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,531评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,539评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,916评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,813评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,568评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,654评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,354评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,937评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,918评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,152评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,852评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,378评论 2 342

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,580评论 18 139
  • 一说到REST,我想大家的第一反应就是“啊,就是那种前后台通信方式。”但是在要求详细讲述它所提出的各个约束,以及如...
    时待吾阅读 3,406评论 0 19
  • 上篇写《聊聊数据库和缓存同步机制》的时候,收到一份读者留言,希望我来谈谈API开发过程中的版本控制。这是一个很好的...
    ForestXie阅读 1,588评论 1 8
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 171,386评论 25 707
  • 今天天气很晴朗,下午出了大大的太阳,感恩阳光。 老公拉我出去逛超市,越来越发现老公的好了,说我一天在家太闷了,让我...
    秀艳的美好生活阅读 130评论 0 1