我正在寻找对Spring REST API的URI进行版本控制的方法，因为在启动新应用程序的情况下，REST API处理新应用程序并支持旧应用程序请求一段时间。但是，每当将版本添加到URI时，我都怀疑通常有哪些数据库，系统实体和URI。
例：
没有版本，请求获取所有用户：
http://host:8080/api/users
使用版本控制：
http://host:8080/v1/users
http://host:8080/v2/users
http://host:8080/v1/products
我正在考虑创建一个用户实体，在定义属性时，我注意到它们不是强制性的，并且该实体始终是最新版本。对于 URI 的"v2"版本，我创建了一个 UserV2DTO，以便它主要为使用所需注释进行验证的用户实体提供服务。对于 URI 的"v1"版本，假设用户没有"dateBirth"属性，这样它会收到一个没有 dateBirth 属性的 UserV1DTO，并且在将 DTO 转换为实体时，Entity.dateBirth 属性为空，因为是必需的。
我想知道的是这是否是一种正确的版本控制形式，因为在数据库中属性不是强制性的，而强制性属性的验证是在 DTO 中？我还想知道是否需要将所有资源的所有 URI 更改为最新版本，或者在"产品"的情况下，它是否可以保留在 V1 中，直到有一天需要只更改它？
如何在 REST API URI 地址中进行版本控制？
真正的答案？ 任何您想要的方式，符合您当地的惯例。
在 REST 中，URI 只是标识符;实际上它们是用于在缓存中查找信息的键。 在 URI 中嵌入信息由服务器自行决定，并仅供其独占使用。
Roy Fielding在领导HTTP/1.1规范工作时定义了REST，他写道
制作真正的 REST API 的原因是为了获得可进化性......"v1"是 API 客户的中指，表示 RPC/HTTP(不是 REST)
举个例子，考虑一下谷歌——你认为这些年来他们有多少种不同的网络搜索实现？ 但是API本身是稳定的：导航到带有书签的主页，在搜索表单中输入数据，提交 - 将数据调度到元数据表单中描述的任何URI。
当然，即使你没有做 REST，你可能仍然需要一个理智的 URI 设计。 在相对 URI 方面，使用路径段对资源层次结构进行分区具有优势，因为随后可以使用点段在层次结构中生成其他标识符。
/v1/users + ../products -> /v1/products
如果您清楚每个版本中是否确实有新资源，或者具有不同表示形式的共享资源，那么您的生活可能会轻松得多。 如果有人改变/v2/users，是否也应该改变/v1/users？ 正确的缓存失效语义是什么？