REST-API 版本控制策略

本文主要是介绍REST-API 版本控制策略，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

管理分布式异构系统的应用程序编程接口 (API) 的方法不同于 Apache Maven 提供的经典工具，后者旨在简化技术上和同质相似工件的组装构建过程。这种经典的依赖管理工具的局限性在管理技术不同且独立的系统之间的 API 的上下文中变得明显，例如，表述性状态传输 (REST-API) 等 API 确保其网络功能。

服务提供商（可能会提供一些已实施的 API 版本）与其消费者之间的相互契约起着至关重要的作用，因此需要另一种方法来通过设计保证契约长期运行。此外，Apache Maven 通过区分三位数字来使用语义版本控制对于 REST-API 来说是不现实的。

因此，所应用的语义方案有意仅区分主要版本，其中每个增量都代表重大更改。在这篇立场论文中，作者强调，为了使 REST-API 的版本控制概念有效且可持续，软件工程师必须了解不同方法的功能和局限性，以及哪种方法最有效地与底层传输的功能保持一致技术。

介绍

应用程序编程接口（API）帮助公司集成应用程序甚至构建新的生态系统。通过 API 促进服务创新和货币化是一种趋势，这在许多领域都得到了认可。通过接口增强的系统不仅在工业中发挥着决定性作用，这决定了工业4.0的一部分，特别是智能工厂，而且在金融领域也发挥着决定性作用，例如遵守开放银行指令。[1][2]

具象状态传输 (REST)-API 的进步为跨异构系统的通信铺平了道路，其中大多数应用程序都具有不同的性质。然而，对 REST-API 版本控制的看法不同，并且构成了一篇很少撰写的论文，不仅从科学的角度来看。在本文中，术语 API 一般指 REST-API。虽然拥护者认为任何 API 都应该采用版本控制标识符，以便为可能存在向后不兼容的更改做好准备，这描述了重大更改的概念，但反对者声称绝大多数应用程序甚至不会受到这种程度的更改因此，根本不需要版本控制。

然而，可维护 API 的设计给许多软件架构师和开发人员带来了许多挑战。尽管已经提出了许多策略来寻找有效的方法来应对重大变更，但当共存 API 的数量不断增加时，所有这些策略都给组织带来了共同的负担。简要介绍状态传输中涉及的每项技术，例如域名系统 (DNS)、统一资源定位符 (URL)、统一资源标识符 (URI) 和超文本传输协议 (HTTP)，对于了解其主要技术是必要的。函数，因为它们中的每一个都构建了各种方法的关键元素。

域名系统

广泛使用的名为 DNS 的翻译服务可将互联网协议 (IP) 地址解析为人类友好的名称，反之亦然，通过利用可分离名称的分层排列，提供全局唯一性、稳健性、可扩展性和发现功能。自大约 30 年前推出以来，DNS 在支持协议和可扩展性方面不断发展。

虽然名称仍然比数字地址更有助于记住对象，但其背后的可识别资源和信息已变得更加通用，尤其是由于近年来应用程序界面的显着增长。然而，无处不在的物联网等新兴技术对这一全球标准的原有特性提出了挑战。

根据参考文献 [3]，DNS 并不是为当今受物联网影响的世界中的移动性、效率和安全性方面的要求而设计的。层次结构越深，解析机制的延迟就会增加。健壮性和敏捷性之间存在另一个矛盾的问题，前者需要管理庞大的命名空间，而子域需要敏捷性以按需识别资源。

网址和统一资源标识符

尽管 URI 和 URL 这两个术语之间有明显区别，但它们通常被认为是等效的，但是，每个术语都是针对特定类型的资源管理而设计的。URI 处理对象的标识，而 URL 则描述可识别元素的位置。然而，由于 URL 也标识对象，因此它与 URI 具有相同的特征，但情况并非相反。[4] 换句话说，URI 是用来标识资源的，这些资源的存在、位置并不重要，因此与 URL 形成鲜明对比。[5]

Web 发明者兼万维网联盟 (W3C) 总监 Berners-Lee 撰文阐述了制定旨在实现 URI 不变的策略的重要性。[6] 此外，酷 URI 的概念旨在防止技术和组织变革期间标识符数量的增加，以符合万维网的架构建议。[7] [8] 相反，如果允许底层技术影响命名方案，那么技术的任何变化都可能对 URL 的关键概念产生不利影响，从而导致任意演变。[4]