代码之家 › 专栏 › 技术社区 › user3237736

restapi:多个版本,单个应用程序?

api-versioning versioning rest java

2

user3237736 · 技术社区 · 7 年前

我正在开发一个restapi,我将很快引入一些突破性的更改,因此需要v2。我们仍然需要对v1进行几个月的并行支持,以便客户机在准备好时有时间切换到新的API。我们的API是通过共享云提供的,我们的所有客户机共享同一个系统后端,特别是一个单一的共享数据库。

然而,我在问自己,我将如何实现这一点,我还没有找到好的文章。我真的不想把我的项目的一个v2分支出来,然后将v1和v2作为单独的应用程序来构建和部署,因为这样一来,我将在两个应用程序中进行维护、错误修复、配置更改等,这是一种双重工作,并带有通常的冗余危险(即:版本之间可能存在不一致)。当然,v2在每种服务中都是一样的,所以大部分代码仍然是相同的。

我很感谢你提供的任何关于如何解决这个问题的建议或资源。谢谢!

3 回复 | 直到 7 年前

1

Sankarganesh Eswaran 7 年前

希望你看到了

API design ensuring backward compatibility

http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/32713.pdf

在同一个应用程序中拥有两个版本的API已经足够安静了

api.mysite.com网站/[版本2]/api/url

不知道为什么需要将v1和v2作为单独的应用程序进行构建和部署?除非您计划在生产中进行零停机时间滚动升级

2

1

jschnasse 7 年前

我想在讨论中提出以下策略,两者都是策略 Continuous Delivery .

基本思想是在客户机和当前实现之间放置一个抽象层。然后介绍抽象层后面的第二个实现。这使您有机会在正常的代码库中继续工作,但可以立即为下一个版本的API提供新功能。

https://martinfowler.com/bliki/BranchByAbstraction.html

功能切换

https://martinfowler.com/articles/feature-toggles.html

3

0

Eric Green 7 年前

如果我面对你所说的情况,我会首先尝试保持我的新版本(v2)与我的第一个版本(v1)向后兼容。如果是这样的话,您只需添加功能并更新API文档,只保留一个活动的代码库。我认为您甚至可以向响应负载添加内容,只要返回的数据不会破坏任何人的代码—就像向现有数据库模式添加字段一样。

如果v2与v1不向后兼容,您可以将v1移到另一个服务器上,并通知您的用户它将在那里放置一段规定的、有限的时间,以便他们有时间进行必要的代码更改以切换到v2,但也要通知他们此版本不再更新,如果他们有问题,他们需要切换到新版本。因此,v2是代码库的主版本,没有其他正在开发的分支。

我不认为这对你有帮助。

4

-1

Roman Vottner 7 年前

v1/v2困境是一个强烈的暗示,您实际上没有一个restapi开始。REST体系结构中的对等方通过客户机交换或多或少标准化的内容,请求表示他们理解的媒体类型。这种技术称为内容类型协商。当然,写得不好的服务器可能会忽略建议的媒体类型,而发送一个客户端不理解的媒体类型。但是,这将阻止客户端与服务器进一步交互。因此,一个性能良好的服务器应该尽力为客户机请求提供服务。

根据菲尔丁的说法:

restapi应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型,或者为现有的标准媒体类型定义扩展关系名称和/或支持超文本的标记。在现有的媒体类型中,应该定义哪些类型的uri,以及在哪些类型的媒体上已经定义好了。[ .]
Source

媒体类型描述了与这种媒体类型交换的有效负载的语法,以及该表示中每个元素的语义。在有意义的链接关系名称和媒体类型的帮助下,服务器可以教客户机下一个可用的选项,客户机可以在完成任务时使用这些选项。一、 e.想一个以前的响应包含链接关系的情况 create 给客户。客户机并不真正知道为了让服务器可以处理某些内容必须是什么样子,比如调用为 创造 application/vnd.xyz-form+json 其中,此媒体类型定义了一些输入控件,客户端可以使用这些控件在目标端点上生成服务器期望的请求表示。与Web类似,自定义表单还包含HTTP操作以及客户端提供的用于发送响应的目标URI,以及最终由服务器首选的表示形式。

REST架构中的客户机不应该关心URI,因此返回一个包含这两者的URI v1 v2 对他们来说应该或多或少是毫无意义的。菲尔丁甚至说 a REST API itself shouldn't be versioned at all

实际上,需要对描述语法和语义的媒体类型进行版本控制,而不是对URI或API进行版本控制。一、如果你看一看基于浏览器的Web(REST的大兄弟),尤其是HTML,你会发现它的设计要求新版本保持向后兼容。一、 e.客户端和服务器接收 text/html 定义的负载将能够处理纯HTML(1.0)到HTML5内容,而不管实际使用的是哪种语法(甚至可能是混合的)。然而,其他类型的媒体可能不会那么宽容。在这里,您可以使用配置文件或注册一个全新的媒体类型,如果您认为新旧媒体类型完全不兼容。

不管怎样,我希望我能对REST体系结构和如何实现这一点有更多的了解。我很清楚,我的建议可能并不容易实现,尽管一旦你得到了它,你基本上就把客户机从你的API中分离出来,并给了后者一个自由发展的空间,同时又不必担心破坏客户机。仍然会有耦合,但是客户端和服务器都将耦合到媒体类型,而不是相互耦合。在创建一个新的媒体类型之前,它可能是值得寻找的 already existing ones