简评:这是 fly.io 分享的一篇文章,讲了他们是怎么对自家 REST API 作版本控制的。另外还有不少其余的技术文章,我的感受还不错,感兴趣的同窗能够看一看。json
API 设计是一个都快被说烂了的主题,已经有太多关于对 Web API 作版本控制很棒的文章了。好比:api
但今天这里仍是想分享一篇,但愿看完能有所收获。: )bash
虽然尚未一个绝对正确的方式来设计一个 API,可是有几个关键想法是许多开发者都赞成的,一个优秀的 Web API 应该是:restful
为了能最好的实现这些理念,关于如何实现 API 的不一样版本目前主要有三种作法:app
在 URI 中标记版本curl
curl https://example.com/api/v2/lists/复制代码
经过解析 URI 中的版本号,客户端能够访问/v1/或/v2/等不一样版本API。ide
在 Header 中标记版本url
curl https://example.com/api/lists/3 \
-H 'Accept: application/vnd.example.v2+json'复制代码
直接不标记版本spa
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 设计有许多不一样的理念和作法,这里也只是其中一种,或许能对你有所启发。
知乎专栏:极光日报
极光日报,极光开发者 的 Side Project,天天导读三篇国外技术类文章,欢迎关注。