Semver：在 Web 应用程序中引入了新的重定向，我需要增加主要版本吗？

Question

我不确定何时使用语义版本控制来增加补丁、次要和主要补丁。

如果我引入了在会话（用户）处于特定状态时执行的新重定向，这是否被视为不兼容的 API 更改，需要我增加项目的主要版本？

你会如何处理这个问题？提前致谢。

Answer 1

在 API 的上下文中，我会说 SemVer 根本不适用；这是一种不同类型的版本控制。 patch 版本对客户端没有意义。在传统版本控制中，补丁将指示没有可见（例如公共）更改的修复。对于 HTTP 客户端，指示版本更改而没有明显的影响实际上是没有意义的，只会为他们增加更多的工作。 SemVer 还意味着表示一系列版本，这对于基于 HTTP 的 API 通常没有意义。最后，API 版本应该被认为是一种媒体类型，Fielding 本人表示这是唯一可接受版本 API 的方式。这是有道理的，因为 99% 的时间，版本之间的差异是通过网络传输的有效负载（例如媒体）。 API 作者倾向于假设客户端使用Tolerant Readers，但这不能保证。他们还倾向于假设存在一些潜规则，即微小的更改以某种方式意味着有效负载是向后兼容的，但是 - 再次 - 不能保证。媒体的任何更改可能不兼容或被客户误解。这与从application/xml 切换到application/json 没有什么不同。

重定向和位置更改不仅可以，甚至在适当的时候鼓励它们。这就是超媒体作为应用程序状态引擎 (HATEOAS) 的本质。使用重定向或任何Location、Content-Location 和Link (RFC 5988) 标头是实现此目的的好方法。只要您链接到的资源的位置不会在版本之间发生变化，就没有理由仅仅因为您移动了它所在的位置而增加版本。

有一个警告，如果您按 URL 段进行版本控制。通过该方法进行版本控制将 API 版本放在 URL 路径中，这违反了 统一接口 REST 约束。例如，v1/orders/123 和 v2/orders/123 不是两个不同的订单，而是具有不同表示（例如媒体类型）的相同订单。虽然人类可能会推断出标识符是123，但根据 REST Uniform Interface 约束的标识符是 URL 路径。这种版本控制风格对于 HATEOAS 是有问题的除非您使用对称版本控制（例如，所有 API 都具有相同的版本）。想象一下，一个客户请求v1/orders/123，你将他们重定向到v2/orders/123或链接到v2/customers/456（来自v1）。客户可能不知道如何处理这种变化。这就是为什么这种版本控制风格是最少 RESTful 的。客户端应该 总是询问他们想要的版本，可以通过媒体类型（最佳）、查询字符串（实用）或标题来询问。在重定向的情况下，查询字符串应在 Location 中包含请求的 API 版本（如果存在）。当客户端向新的Location 发出请求时，媒体类型和标头方法将内在流动。