我正在寻找支持更改REST服务中使用的模型版本的支持的好工具。我的梦想工具会做类似的事情：
在我的特定情况下，我不需要进行反向转换，因为我的REST服务只提供数据查找而且从不存储东西，但我不介意使用工具同时执行： - ）
我正在考虑的解决方案是在我的pojo（版本+名称）中添加自定义注释，并根据版本号创建一个基于我的pojo生成JSON / XML的代码生成器。虽然在这里我觉得我正在重新发明轮子。
编辑： 以下是可以从版本1到版本1.1进行更改的示例：
版本1： 人 名字 名字
版本1.1 人 名字 姓 出生日期
如果您使用版本1.0访问API，则不会获得birthdate属性 - 它仅在1.1版中可用。我希望工具支持使这些服务可用，我可以配置授予我的pojo（目前是1.1版本），我想提供一个不显示这些值的1.0版本。
模型的其他合法更改可能是删除属性或重命名属性（甚至重命名实体）。
编辑2： Digital Joel在评论中提到，关于API版本控制的讨论，您应该阅读https://stackoverflow.com/posts/9789756/。
退出版本控制的简单方法是不要进行向后突破的API更改，而是改变业务，因此这并非总是可行。我的兴趣在于如何使这些变化更容易处理，因此我的问题。
编辑3： 我已经找到了可能有助于这个过程的工具，但仍然没有任何能够以良好的方式与休息相关联的工具。以下是我到目前为止找到的链接：
答案 0 :(得分：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
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;
}
答案 1 :(得分：1)
我不知道有任何自动版本化RESTful API的工具。有关版本控制REST的大讨论，请阅读Best practices for API versioning?。
在规划RESTful API时，我花了相当多的时间研究这个问题，我们得出的结论是，我们会以不引入重大变化的方式发展。如果需要进行重大更改，那么我们会将其作为新资源公开，而不是尝试在自定义标头或mime类型中使用版本信息。但是，对于你的问题，这意味着在我身边工作，这更有动力避免做出重大改变。
说到工具，我非常怀疑你会找到一些可以自动进行支持多个版本的RESTful API所需的更改的东西。它需要一个工具来理解模型的两个版本之间的差异，以及API中的所有交互。
如果您遵循REST的HATEOAS原则，那么来自给定位置的所有目标也都包含在响应中，在这种情况下，您可以使用类似REST支持Spring MVC中的请求映射来保留版本号从客户端给出一个入口点的所有URL，但您仍需要维护每个版本的控制器和模型。
答案 2 :(得分：1)
这不是您可能期待的答案，因为我不使用开源外部工具为我做繁重的工作。我使用自己的工具。
我使用泽西岛。我在@Path声明中使用了/ vx /。
由于REST apis代表合同，我不相信自动创建。然而，我在一个不太复杂的maven插件中完成了一个XLST工具。）我保持简洁的xml版本并转换为gensrc中的Jersey类。
我发现v1有一个特定的路径和矩阵/查询参数，当时设计是唯一的。当我开发v2时，我经常发现我需要支持其他参数或重构我的网址以便更好地理解。我只需要更改xml文件。
我的生成引擎将使用MyAPIv1.java和MyAPIv2.java创建我的Jersey层，并根据时间的需要进行注释。
所以我想保留对版本控制的控制，并且使用自动/工具可能是有害的。
同样，使用规范是完全控制但不能完全实现薄层的好方法。
所以这里没有雪茄，但这可能会有所帮助。
答案 3 :(得分：0)
只是一个想法，但是让你的api向后兼容会不会更好;那么你只需要为你的代码库进行版本控制，那就不那么麻烦了吗？
答案 4 :(得分：-1)
您是在谈论在开发领域（维护api的版本以供给用户）或在实时服务器世界（运行时的内容协商）中为您开发此版本的内容吗？
对于前者，看看像maven，ivy，gradle这样的工具......这就是它们的用途。我个人使用maven，因为它是我最了解的那个，但是它们都允许你发布带有版本的jar文件。