我不确定何时使用语义版本控制来增加补丁，次要和主要。
如果我在会话(用户)处于特定状态时引入新的重定向，这是否被认为是不兼容的API更改，需要我增加项目的主版本?
你会如何处理这种情况?提前谢谢。
在API的上下文中，我会说SemVer根本不适用;这是一种不同类型的版本控制。补丁版本对客户端没有意义。在传统的版本控制中，补丁表示没有可见(例如公开)更改的修复。对于HTTP客户端来说，指示没有明显影响的版本更改实际上是没有意义的，只会给他们增加更多的工作。SemVer还表示一个版本范围，这对于基于http的api来说通常没有意义。最后，API版本应该被认为是一种媒体类型，Fielding自己指出这是唯一可以接受的API版本的方法。这是有道理的，因为在99%的情况下，版本之间的差异是通过网络传输的有效载荷(例如媒体)。API作者倾向于假设客户端使用tolerance reader，但这不能保证。他们还倾向于假设存在一些潜规则，即一个微小的更改在某种程度上意味着有效负载是向后兼容的，但这一点也不能保证。媒体的任何更改都可能导致不兼容或被客户端误解。这与从application/xml切换到application/json没有什么不同。
重定向和位置更改不仅是可以的，在适当的时候甚至是鼓励的。这就是超媒体作为应用程序状态引擎(HATEOAS)的本质。使用重定向或任何Location、Content-Location和Link(RFC 5988)标头都是实现这一目标的好方法。只要你链接到的资源的位置在不同版本之间没有改变，就没有理由仅仅因为你移动了它所在的位置而增加版本。
有一个警告，那就是如果你的版本URL段。该方法的版本控制将API版本放在URL路径中，这违反了统一接口REST约束。例如，v1/orders/123和v2/orders/123并不是两个不同的顺序，而是用不同的表示(例如媒体类型)来表示相同的顺序。虽然人们可能推断标识符是123，但根据REST统一接口约束的标识符是URL路径。这种版本控制风格对于HATEOAS来说是有问题的，除非你使用对称版本控制(例如，所有api都有相同的版本)。假设客户端请求v1/orders/123，您将它们重定向到v2/orders/123或链接到v2/customers/456(从v1)。客户可能不知道如何处理这个变化。这就是为什么这种版本控制风格是最不RESTful的。客户端应该总是询问他们想要的版本，可以通过媒体类型(最佳)、查询字符串(实用)或标题来请求。在重定向的情况下，查询字符串应该在Location中包含请求的API版本(如果存在的话)。当客户端向新的Location发出请求时，媒体类型和报头方法将在本质上流动。