写点什么

REST 及其版本控制

  • 2010-06-17
  • 本文字数:2048 字

    阅读完需:约 7 分钟

Ganesh Prasad 最近思考的问题是与 REST 相关的最棘手的问题之一:基于 REST 架构的服务版本控制。Ganesh 通过一个示例说明:

假设有一个资源,它的标识是这样的,“/customers/1234”。人们通过 PUT 修改这个资源的状态。[但是]REST 如何处理 PUT 对应的业务逻辑的变更呢?

因为无法通过修改操作名(如,指定 PUTv2)的方式标识服务的业务逻辑发生的变化,一种可能的做法是修改 PUT 使用的 URL,与此同时维护原有的资源标识,Ganesh 描述到:

如 PUT /customers/v2/1234,这不同于客户端的原有标识 /customers/1234。

该方法类似于 Peter Williams 在几年前谈到,而且其他人甚至在更早就谈到的反模式。Peter 在 2008 年如是说:

我非常痛恨这种方法,其隐含的意思是一个版本的 API 与另一版本的 API 表征不同的资源。它迫使客户端作出进退两难的选择,不是同时支持多版本的 API,就是打破 REST 的核心限制之一。例如,一个 V1 版 API 的客户保存了 URL 引用(该 URL 中包括版本标识),一段时间后客户端更新到新版的 API。 此时,客户端支持该 API 的多个版本,因为所有之前保存的 URI 全部指向旧版本的 API,或者必须要将这些 URI 转接到新版 API。URI 转接打破了 REST 的将多媒体当作应用程序状态引擎(HATEOAS)的限制,而支持多版本的 API 是维护工作中的噩梦。

Peter 建议使用定制媒体类型与(最终必将发生的非向后兼容性变更的)内容协商的结合进行版本控制。

该方法的确会导致新建媒体类型,但是媒体类型是低成本的,所以我们可以,而且应该,需要多少媒体类型就创建多少。如果能正确使用,内容协商可用于解决 REST/HTTP 服务接口的版本控制问题。

但是,回到 Ganesh 以及最初的修改 URL 的方法,他也不同意这种方法。

首先,如果认为只有两处(动词以及资源)可以存放业务逻辑的不同版本,那就是一个错误。第三处是所提交的数据中……但此例仅仅引发了我对版本控制根本的探究。

进而他提出了 REST 与 SOA 所需的版本控制的问题,它问道,首先版本控制是什么,其次为什么需要它?

我认为服务版本控制是一种机制,它使我们能够以消费者可见的方式同时维护两组或多组业务逻辑的版本。

首先他问道,为什么要对消费者可见,如果服务能够区别不同的消费者类型,那么它就能在内部为不同的调用者(客户端 / 消费者)应用不同的业务逻辑?接着它又进一步提出问题:我们为什么要同时维护不同版本的业务逻辑呢?

一个有趣(又迂回)的答案是,业务逻辑通常需要对消费者可见,所以新版的业务逻辑也需要以消费者可见的方式与其旧版本进行区别。这往往被描述成是对旧消费者的支持,比如,消费者在某方面依赖于旧版本的业务逻辑的服务消费者。

支持旧客户的目的是确保现有的契约和 SLA 不会因为服务的(悄然)更新而被破坏。这就引出了 Ganesh 的又一问题,版本控制的问题的解决办法可否不通过使用显式的版本,而在对具体实施细节进行抽象时找到呢?也许服务契约太细节了以至于在变更发生时显得脆弱。(类似于过去 SOA 背后的一个重要原则,松耦合与紧耦合的思想)

Ganesh 接着通过一个例子描述了如何使用这种方法解决版本控制的问题。在该例中,一个虚构的开发人员在已有服务消费者的情况下悄悄地完成了对服务的业务逻辑的变更。

第一个问题是,新的业务逻辑能否应用于所有的消费者,或者我们是否需要跟踪“旧”消费者并继续为他们保留旧的业务逻辑?如果我们能够为所有消费者升级到新的业务逻辑,那是当然没有任何问题的。接口继续保持不变,客户端应用程序将数据 POST 到相同的 URI,请求接着被转发到新建资源的地址……所应用的业务逻辑是全新的,但是客户端不会从接口中感知到变化……

但是,当然也有可能根本无法做到这样,这时就需要维护业务逻辑的多个版本。Ganesh 接着描述了这种情况发生的几个可能的原因:

  • 客户端应用程序应该提交的数据有变化,这种变更不可避免地要让消费者知情,而且不得不使用新契约进行交互。
  • 另一商业原因是区分两类客户,也许是要奖励长期的客户,为他们提供更好的服务,不过该变化不会从客户端提交的数据中察觉出来。
  • 客户端应用程序可能“了解”旧版本的服务行为并依赖于这些行为,这种情况下,需要使用新的版本已避免 d 对遗留客户造成破坏。

Ganesh 认为,第三种情况是人为的,它意味着通过消费者和服务实现之间的显式依赖关系破坏了服务的松耦合性。

相反,第一种和第二种情况都有相应的解决方案。如果由客户端提交的数据要发生改变,那么这本身就是一种区别新消费者与旧消费者的方式,从而可以为他们提供不同的业务逻辑。换言之,我们仅需告诉新消费者他们需要对 POST 的数据作出的修改。旧消费者什么都不用做。此外,如果我们能够在某种程度上得知消费者是旧消费者,那么,即使它既提交的数据没有明显的区别,我们也能透明地应用不同的业务逻辑。

他这样总结自己的观点……

服务的版本不是接口细节,而往往是在接口中泄漏的实现细节。

服务的版本控制问题是许多领域里的常见话题,不仅仅是REST。然而,Ganesh 坚信REST 为该问题提供了更好,更自然的解决方法。


查看英文原文: REST and versioning

2010-06-17 04:484652
用户头像

发布了 184 篇内容, 共 86.8 次阅读, 收获喜欢 8 次。

关注

评论

发布
暂无评论
发现更多内容

《编程的原则》读书笔记(四):七个设计原则

Chares

软件工程 软件开发 编程原理 软件开发原则

Disney 流媒体广告 Flink 的应用实践

Apache Flink

大数据 flink 实时计算

软件测试/测试开发 | 如何模拟真实使用场景?mock 技术来帮你

测试人

软件测试 自动化测试 接口测试 测试开发 Mock

重磅!持续应用安全(CAS)白皮书发布,云起无垠入选

云起无垠

Fuzzing CAS白皮书

云上的米开朗基罗:在不确定时代,寻找建筑般的确定性

脑极体

Date & Time组件(下)

芯动大师

datepicker timepicker calendarview

华为运动健康服务Health Kit 6.9.0版本新增功能揭秘!

HarmonyOS SDK

HMS Core

web 3d的开发技术方案选型

好孩子

web3d

CAP定理

threedayman

分布式 架构设计 java; 基础

喜讯!云起无垠获评“2022中国科创好公司”

云起无垠

网络安全 Fuzzing 2022中国科创好公司

数据湖(十九):SQL API 读取Kafka数据实时写入Iceberg表

Lansonli

数据湖

数据湖(二十):Flink兼容Iceberg目前不足和Iceberg与Hudi对比

Lansonli

数据湖

[原生1v1视频源码]社交市场趋于饱和,出海成为1v1语聊平台的新选择

山东布谷科技胡月

社交APP出海 视频社交APP开发 1v1交友app开发 一对一视频语音系统搭建

打造数字海南,中国电信天翼云赋能海南自贸港智慧发展!

天翼云开发者社区

dcm4che 解析 修改 保存 dicom文件

JefferLiu

ElasticSearch必知必会-进阶篇

京东科技开发者

ES 集群 索引技术 Elastic Search 企业号 1 月 PK 榜

为什么数字化转型需要“低代码”?

元年技术洞察

DevOps 低代码 数字化转型 低代码平台

架构实战营 - 模块 4- 作业

zealot0317

天翼云位居中国私有云市场领导者象限

天翼云开发者社区

玩转云端| 天翼云数据加密,护航企业数据安全

天翼云开发者社区

响应式流的核心机制——背压机制

老周聊架构

响应式编程

在农业银行做开发是什么样的体验?

程序员大彬

Java 开发

使用 NineData 实现备份集的实时查询

NineData

数据库 数据 NineData 备份集 实时备份

软件测试/测试开发 | 服务端接口自动化测试, Requests 库的这些功能你了解吗?

测试人

软件测试 自动化测试 接口测试 测试开发 requests

我的2022

劼哥stone

2022年终总结

BI 可视化工具不只有视图,还有报表

搞大屏的小北

数据可视化工具 DataEase

“低代码+PaaS”的技术创新实践

元年技术洞察

方舟 低代码 数字化转型 低代码平台

1 📖 《JavaScript高级程序设计》__ 什么是JavaScript?

HoMeTown

JavaScript #读书 前端‘’

头号玩家!天翼云蝉联专属云服务市场榜首

天翼云开发者社区

1分钟带你学会MySQL覆盖索引,让你的SQL更高效

程序员拾山

MySQL 索引 覆盖索引

工信部电子标准院授予阿里巴巴9个开源项目“优秀”评级

云布道师

阿里云

REST 及其版本控制_SOA_Mark Little_InfoQ精选文章