在我们的应用程序中，我们采用了URI版本控制方案。
例如：server.com/v2/resource1
现在团队中有两种思想流派：
我们不应该向客户端公开资源级别的版本，而应该给他们一个版本。如果他们调用/ v2 / resource1，而resource1不存在v2，那么我们应该在内部将请求重新路由到/ v1 / resource1。
我们应该向客户端公开资源级别的版本控制。如果没有对resource1调用/ v2 / resource1和v2，则我们应该向客户端发送简单的404错误响应。
第一种方法的好处在于，客户端不必担心版本控制的详细程度。但是，这种方法使我们无法进行端点的增量重构，因为一旦暴露了v2，对于客户端，每个资源都是v2版本，则会破坏向后兼容性。
第二种方法使我们可以更好地控制增量重构，并从客户端的角度清楚地了解资源版本。
有想法吗？
根据REST规范，建议不要在URL中包含版本信息，因为REST URI应该引用唯一资源。但是，几乎所有最流行的基于REST的API都不遵循此建议。
要使事情变得容易，请在v2中部署resource1（如果没有可用的新版本）。 如果有可用的新版本，请在v2中部署该版本。
让两个版本都运行，并留出一段时间让客户端升级并在一段时间后删除较旧的版本。
, IMO API版本控制应该在API级别（请注意：“ API”是指一组资源/路由及其操作）。即使您只需要更改单个路由的单个特定操作的版本，也可以；所有现有的API操作也应使用新版本进行访问，例如您不应具有在/api/v2/template/thing可以访问一个操作的情况，但是在同一API中的第二个操作只能在/api/v1/template/item而不是/api/v2/template/item进行访问。这会给API使用者增加很多困惑。
我们在我目前的公司中使用.NET Core。为了实现上述目的，API控制器类的所有已知版本都带有ApiVersion属性标记。不是最新版本的特定操作会用MapToApiVersion属性标记-最新操作版本不会用特定的MapToApiVersion标记，例如
[ApiVersion("1.0")]
[ApiVersion("2.0")]
[ApiController]
[Route("api/v{version:apiVersion}/template/test")]
public class TestController : ControllerBase
{
[HttpGet]
[MapToApiVersion("1.0")]
public IActionResult Get()
{
return Ok(nameof(Get));
}
[HttpGet]
public IActionResult GetV2()
{
return Ok(nameof(GetV2));
}
在上面的示例中；对于没有明确处理的任何版本，GetV2操作基本上是默认路由。通过HTTP GET到/api/v2/template/test。
这种方法为您带来好处； a）客户端不必担心版本控制的详细程度，b）仍然可以对端点进行增量重构，而不会破坏向后兼容性。