写点什么

RESTful 服务的版本控制策略

  • 2010 年 3 月 10 日
  • 本文字数:1403 字

    阅读完需:约 5 分钟

本文中,Stu Charlton 归纳了 RESTful 服务版本控制的多种选择,他在本书的前言中 这样说道“这些概念是很难描述的棘手概念,我实在不想以这样的主题写一本小书”。他把各种版本控制的问题总结成两类:数据版本控制,用于控制资源本身,那么,对于任何给定资源,跟踪其状态就变得可能; 语言版本控制,指得是协议本身,即展现。

URI 版本控制 […] 是一种设计决定,用于当资源不随时间的变迁而变化时,我们为状态的改变创建新资源(类似于管理数据库中的时间序列数据)。

语言扩展或版本控制,相反,状态不改变,而是数据的展现被更改。

Stu 赞同 David Orchard 所著的关于版本控制能力策略的 W3C TAG 的 草案,该草案阐明了向后,向前以及不兼容变更的复杂之处。他说,“语言的扩展需要深思”,他还强调:

规则#1:倾向于以向前且 / 或向后兼容的方式对语言进行扩展。版本标识器是表示不兼容变更的最后的一招

他用下表对文档进行了归纳:

消费者 生产者 向后兼容 - 查找版本通知

  • 替换或二者相安无事
  • 通过带外通道或链接进行版本通知

向前兼容 - 必须接受未知

  • 如果保持状态,必须保留未知

  • 版本标识替换模型

  • 媒体类型规范显示定义消费者向前兼容 期望(以及 / 或者使用机器可读的模式去表示向前兼容的扩展域)。

不兼容 - 检查版本标识

  • 二者相安无事或断裂替换

接着,他定义了本表中使用的一些术语,如版本通知替换相安无事版本标识 等。此外,他还定义了生产者和消费者之间如何处理在不同兼容场景的“语言”中出现的未知元素。他检视了多种提供版本标识的策略,并针对这些策略的应用,给出了他个人的优先级顺序。

媒体类型内容中的版本标识

这样的例子有很多,如 HTML DOCTYPE,XMLNS 的某些使用或 PDF 文档中的某个版本标识。[…] 这是大多数 Web 媒体类型长期以来的工作方式,成功程度各有不同。但是,要注意,那些格式都是经过考虑了向前兼容的长远的设计定义的。

MIME 类型中的版本标识

[…] 这里的好处是它支持互不相干的版本控制且不会影响到 URI 空间。 […但是…] 这种做法带有明显的逃避多媒体的意味并试图把问题推到网络架构 (HTTP 以及 / 或者 URI)的另一层次。如 application/vnd.mytype;version=2

URI 中的版本标识

很明显,当资源本身的语义发生变化时我们是在铸造 URI。所以,如果它们随语言而修改,那我们铸造了新的 URI,如 http://example.com/data/v1/po/123

另一个问题是书签,在数据系统中它实际上是“外键”。任何有关系型数据库背景的人都知道主键实际上不会改变,因为要把其更改传播到外键是很昂贵的工作。

他推荐阅读 Subbu Allamaraju 所著的《RESTful Web Services Cookbook》一书的第 13 章并从中学习更多相关的知识。他也给自己的文章做了如下总结:

  1. 更愿意使用扩展的,向前以及向后兼容的语言以及替换方法。注意 W3C TAG 关于版本标识的观点。
  2. 当你在 URI 中使用版本标识是要审慎,因为好的 URI 是不会更改的。
  3. 对于相安无事的部署,始终在你的媒体类型或链接关系中包含一个块,用于指向新 / 旧版本,并在消费者更新它的缓存值是延迟更新引用。使用永久的转发使绑定到旧的语言版本的 URI 退役。
  4. 如果资源语义发生变化,对 URI 进行版本控制,但是对待消费者要礼遇,要确保通往新 / 旧资源的链接。

Stu 的文章尝试了把所有 RESTful 服务的版本控制的解决方案中的元素结合到一起,然而,在这些策略间关于谁是正确的选择争论却一直没有停止过。


查看英文原文: Versioning Strategies For RESTful Services

2010 年 3 月 10 日 19:562345
用户头像

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

关注

评论

发布
暂无评论
  • 规范设计(上):项目开发杂乱无章,如何规范?

    一个项目的规范设计主要包括编码类和非编码类这两类规范。今天,我们一起学习开源规范、文档规范和版本规范。

    2021 年 6 月 1 日

  • 争论:REST 需要描述语言吗?

    追踪上周在此讨论的关于REST vs. WS-*的争论,值得注意的是,以REST化服务契约为主题的争论在最近几天日嚣尘上。

  • API 风格(上):如何设计 RESTful API?

    今天,我们一起来看下如何设计应用的API风格,我会介绍两种常用API风格中的一种,RESTful API。

    2021 年 6 月 22 日

  • 重新考虑“代码优先”的 Web 服务

    在本文中,Dennis Sosnoski质疑了Web服务开发的至理名言——“契约优先(contract first)”,即“由WSDL开始(start-from-WSDL)”优于“由代码开始”。他展示了如何使用JiBX框架来实践“由代码开始(start-from-code)”的开发,且规避了其缺点,尤其是没有将实现和接口耦合得过于紧密。

  • RESTful Web Services Cookbook 中文版

    现在说起REST(表述性状态转移),相信大家一定都不会觉得陌生,因为人们对它的认识早已经过了WHAT和WHY的阶段。但在真正要将这种架构风格落地下来的时候往往又会让人有些不知所措,原因就在于我们对HOW关注的太少了。《RESTful Web Services Cookbook》的出现正好弥补了这一空缺,书中包含了大量与设计、实现RESTful Web服务相关的内容,它们都是在日常的设计和开发过程中会经常遇到的东西。本书采用了HTTP报文作为范例,而非具体的开发语言,这消除了语言的限制;而问题描述、解决方案、问题讨论的编排形式让本书也能充当手册使用。相信《RESTful Web Services Cookbook》一定能在你实践REST的道路上助你一臂之力。

  • Web API 的版本控制方案分析

    源于对OpenStack Api版本控制约束问题的探讨,Mark Nottingham在他的博客中分析了云中Web API的各种版本控制机制。

  • 服务发布和引用的实践

    今天我将以XML配置方式为例,给你讲解服务发布和引用的具体实践以及可能会遇到的问题。

    2018 年 9 月 15 日

  • GOTO Berlin: Web API 设计原则

    在邮件列表和讨论区中有很多有关于REST和Web API的讨论,而在GOTO Berlin大会上,InnoQ的首席顾问Oliver Wolf分享了他对这些讨论的一些见解,包括端点、领域模型、缓存、版本等内容。

  • 工整与自由的风格之争:SOAP 和 REST

    它们来自两个不同的时代,却同时活跃于当今的互联网,并担当着重量级的角色,影响了一批新技术的诞生。

    2019 年 9 月 18 日

  • REST 及其版本控制

    REST环境中的服务版本控制问题被人们一次又一次地提及,这次Ganesh Prasad提出了一个方案,它不再更改服务的URL,而是首要考虑将版本控制背后的根本原因。

  • 聊聊 Kafka 的版本号

    今天我想和你聊聊如何选择Kafka版本号这个话题,因为它实在是太重要了,我觉得它甚至是你日后能否用好Kafka的关键。

    2019 年 6 月 13 日

  • 切勿版本化 Web API

    在最近的一次演讲中,Sebastien Lambla指出,通过在URI中增加版本或者使用带有版本的媒体类型将Web API版本化在开放网络上是行不通的。我们真正需要的是,协定随着我们需要的变化而演化。此外,他还描述了避免版本化需求的方法。

  • 在 RESTFul API 中使用 HATEOAS 的好处

    Sun公司的Craig McClanahan给为什么现有“REST”API没有真正使用RESTful服务中的“超媒体即应用状态引擎(HATEOAS)”提供了答案。他从最近参与的Sun云计算API 设计中举例说明了这样做的好处。

  • Thomas Erl 的《SOA 设计模式》中的 3 个模式

    这篇文章将给读者奉上3种服务目录的治理模式:规范表述、元数据集中和规范版本控制,三者都摘自Thomas Erl编著的《SOA设计模式》的第10 章。它们是85个模式列表中的3个成员,所有这些模式都源自于经测试和验证的SOA实践,并为企业架构师和开发者探寻和构建坚实的SOA解决方案提供帮助。

  • RESTful 世界里的 Cool URI

    假想一下,如果要以最小的集成代价实现一个分布在全世界范围的信息空间,用它来共享机器可识别的数据,会怎么样?这是关于REST的吗?不是的。根据 SWEO的说法,这跟语义网有关。那些Cool URI有助于实现这种方式。所以,去看看RESTful SOA URI是不是也很“酷”可能是值得的。

  • 基于资源的架构:资源元数据

    在“基于资源的架构”系列的第二篇文章中,Brian Sletten讨论了REST带来的好处、资源由什么构成、元数据与资源关联,数据元数据、SPARQL、RDF、RDF事实表达、RDF三元组与RDF 查询的公共模型中的陷阱,以及一些RDF查询示例。

  • 深入浅出 REST

    在这篇文章里,Stefan Tilkov对REST(表述性状态转移)——万维网背后的架构——做了一次非常实用的介绍,主要包括可确认的资源、链接和超媒体、标准方法、多重描述以及无状态通信等。

  • 面向资源的架构:REST 的另一面

    这是面向资源的架构系列中的第一篇文章,在这篇文章里,Brian Sletten讨论了REST架构风格,SOA的历史,SOAP与WS-*,语义网,URL作为标识符,URI与URN,自由的形式,逻辑连接的延迟绑定系统,HATEOAS以及语义网对软件系统带来的影响。

  • 你能写出正确的网址吗?

    只要你清楚了URI的格式,就能够轻易地“破解”地址栏里各式各样的长串字符了。

    2019 年 6 月 21 日

  • 微软宣布在 Azure API 管理中预览 OpenAPI 规范 V3

    最近,微软宣布在Azure API管理中支持OpenAPI规范V3,他们的服务允许创建、发布、监控和维护API。OpenAPI规范的使用是通过OpenAPI.NET SDK完成的,并支持从它们的实现中抽象出API定义。

发现更多内容
RESTful服务的版本控制策略_SOA_Dilip Krishnan_InfoQ精选文章