Knu*_*ubo 9 java rest data-migration model
我正在寻找好的工具来支持改变REST服务中使用的模型版本的支持.我的梦想工具会做如下:
在我的特定情况下,我不需要进行反向转换,因为我的REST服务只提供数据查找而从不存储东西,但我不介意使用两种工具:-)
我正在考虑的解决方案是在我的pojo(版本+名称)中添加自定义注释,并根据版本号创建一个基于我的pojo生成JSON/XML的代码生成器.虽然在这里我觉得我正在重新发明轮子.
编辑:以下是可以从版本1到版本1.1进行更改的示例:
版本1:人名字姓
版本1.1人名firstname birthdate
如果您使用版本1.0访问API,则不会获得birthdate属性 - 它仅在1.1版中可用.我想要工具支持使这些服务可用,在那里我可以配置授予我的pojo(目前是1.1版本),我想提供一个不显示这些值的1.0版本.
对模型的其他合法更改可能是删除属性或重命名属性(甚至重命名实体).
编辑2:数字Joel在评论中提到,关于API版本化的讨论,您应该阅读https://stackoverflow.com/posts/9789756/.
版本控制的简单方法是不要进行向后突破的API更改,而是改变业务,因此这并不总是可行的.我的兴趣在于如何使这些变化更容易处理,因此我的问题.
编辑3:我已经找到了可能有助于这个过程的工具,但仍然没有任何能够以良好的方式与休息相关联的工具.这是我到目前为止找到的链接:
正如在一个答案中所提到的,可能没有可用于API的自动版本控制的工具.
我们可以通过两步方法解决这一挑战:
1)API的版本信息 关于最佳实践的争论很多.两个最受欢迎的是:
(i) URI redesign - putting version info in URI like
http://something.com/v1.0/resource1/ or
http://something.com/resource1?ver=1.0
(ii) Using HTTP Header - putting version info in Accept/Content-Type
header keeping URI intact like
#
GET /something/ HTTP/1.1
Accept: application/resource1-v1.0+json
Run Code Online (Sandbox Code Playgroud)
2)使用json/xml库的相同pojo的多个版本
一旦版本信息与我们一起,我们必须相应地生成资源.有许多json和xml库,我们可以使用它们维护相同pojo的多个版本,并仅基于版本序列化所需的属性.谷歌gson java库在这方面很有用.查看 https://sites.google.com/site/gson/gson-user-guide#TOC-Versioning-Support
public class Person{
@Since(1.0)
private String firstname;
@Since(1.0)
private String lastname;
@Since(1.1)
private String birthdate;
}
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
2818 次 |
| 最近记录: |