用于Java版本的REST模型的好工具

Knu*_*ubo 9 java rest data-migration model

我正在寻找好的工具来支持改变REST服务中使用的模型版本的支持.我的梦想工具会做如下:

  • 我的pojo +版本1.0 config/transformer =>我的模型1.0的服务可用
  • 我的pojo +版本1.1 config/transformer =>服务可用1.1我的模型

在我的特定情况下,我不需要进行反向转换,因为我的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:我已经找到了可能有助于这个过程的工具,但仍然没有任何能够以良好的方式与休息相关联的工具.这是我到目前为止找到的链接:

sha*_*lic 9

正如在一个答案中所提到的,可能没有可用于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)

  • 好一个!我不知道gson有版本支持.你值得赏金. (3认同)