我们有基于URL的API版本控制策略。我有几个场景要添加新的端点，在那里我找不到任何战略参考。
场景1:具有从版本v1到v4不等的端点的现有API。很少有端点达到V2，很少有达到V3，很少有达到v4。在这种情况下，如果我必须添加一个新端点，我应该在V4开始新端点的版本吗?有什么标准吗?
场景2这是另一种情况。其中一个API GW跨越多个微服务，微服务按网关内的资源分组。所以资源对服务有一对一的映射。同样，这里的两个资源存在不同的API版本。很少有资源达到V3版本，很少有资源达到v5版本。如果需要将新端点添加到已经升级到v3的资源中，我们是应该在v3中添加新端点，还是应该创建v5版本的资源来添加该特定端点?
任何建议都会有帮助的。
你不可能找到一个标准的做事方式。最接近标准的是Fielding和HTTP规范本身所说的内容。你应该预料到这些问题会引起许多主观意见。以下是我基于经验和对规范的深刻理解而提出的偏见意见。
从概念上讲，向现有API添加新端点没有实际问题。如果你的API是公共的，并且带有公共文档，那么这可能会产生问题。一旦API版本发布，它应该是不可变的，以便客户端可以依赖它。如果您要在API中添加表面积，那么我建议您创建一个新版本。如果你不确定这个版本最终会变成什么样子，你可以从一个预发布版本开始;例如:4.0-preview.1.
N-2支持的版本。
你已经选择了版本按URL段，所以没有回头路。当版本不对称时，这种方式的版本控制会导致由不同url组成的蜘蛛网。这只是您可能遇到的众多问题之一。当通过URL进行版本控制时，除非版本是对称的，否则超媒体几乎是不可能实现的。最终，URL段的版本控制是而不是RESTful，尽管很流行，因为它违反了统一接口约束。URL路径是资源标识符。v3/order/42和v4/order/42不是不同的资源，它们是不同的表示。以同样的方式，我可以要求order/42作为application/json或application/xml，但它们不是不同的API版本，即使它们看起来完全不同。
v2/order/42并且它有到customer/42的链接，但是CustomerAPI支持2.0和3.0，您如何知道提供哪个链接?如果客户端只知道如何使用v3/customer/42，而你给了他们v2/customer/42，这可能会破坏他们。此外，如果CustomerAPI根本不支持2.0，会发生什么?OrderAPI必须错误地假设v2是有效的，或者它必须耦合到知道支持哪些版本;两者都不好。在所有情况下，服务器仍然不知道客户机真正想要什么。客户端有责任告诉服务器它想要什么。所有其他版本控制方法都没有这个问题，因为url总是一致的。假设您使用api-version(另一种流行的选择)按查询字符串进行版本。如果您提供到customer/42的链接，那么无论API版本如何，该链接都是有效的。客户端的工作是了解并附加?api-version=<value>，以向服务器指示它们希望如何查询资源。这就是为什么Fielding说媒体类型协商是唯一的API版本的方式。很难与G.O.A.T争论，但是使用查询字符串或其他标头并不显式违反任何约束，即使媒体类型协商会更好。