arr*_*che 5 rest spring-data-rest
我在Spring Rest Data的官方网站上找不到关于API版本的任何信息
我在Spring上找到了关于REST API的Joshua Long演示文稿
API版本可以通过以下两种方式之一实现:
第一种方法有一些问题在这里描述
这是一个有趣的话题。spring-data-rest 的文档没有提到版本控制的最佳实践。
根据我对 spring-data-rest 的了解,如果不实现自定义控制器,就不可能实现媒体类型版本控制。
但当然,当前的功能允许基于 URI 的版本控制:
com.company.v1.MyEntity或com.company.MyEntityV1在存储库中用于@RepositoryRestResource在 URI 中包含版本
@RepositoryRestResource(path = "/v1/shops")
因此,当您对 API 进行重大更改时,您始终可以创建新的实体版本,并使用新存储库在 API 上公开新版本。
编辑:我们在团队中讨论了这个话题,我想分享一些关于 REST API 版本控制的有趣的新想法。
我想我们都同意上面概述的想法不是一个优雅的想法。它引入了大量代码重复,当您关闭旧版本时,您必须将其从代码库中删除 - 这可能比您想象的要困难。同时,您必须在代码库中维护两个版本。你总是想避免这种情况。
那么有哪些替代方案。你可以做我们在微服务世界中经常做的事情——将复杂性推到基础设施上。在微服务基础架构中创建和运行新的运行时相当容易,因此我们可以选择运行同一服务的两个不同版本。旧版本提供旧 API 版本,新版本支持我们的新版本。一个API网关可以接管路由基于HTTP头(接受或内容类型)或包含在URI版本信息,例如。如果您想摆脱旧版本,只需关闭运行旧版本的运行时即可。我认为这可以是一个优雅的解决方案,可以保持您的代码库干净。
您的基础架构可能已经支持运行同一服务的不同版本以支持蓝绿部署方案。这意味着您已经拥有一些可以构建的路由功能。
此外,我认为如果您支持蓝绿部署方案(您应该这样做),您必须保持版本之间的数据库架构版本兼容(例如,您的服务的旧版本需要能够在新架构版本上运行)。如果您必须保持这种级别的兼容性,在大多数情况下避免 REST API 版本控制可能并不难。因此,您不会被迫经常这样做——也许只有在您进行根本性更改时才会这样做(无论如何您都不会在同一个代码库中进行更改)。
| 归档时间: |
|
| 查看次数: |
2588 次 |
| 最近记录: |