Tag: 版本化

版本化REST API和供应商特定的内容类型

我在这个主题中阅读了很多关于REST API版本的内容： API版本化的最佳实践？ 因此，我想使用HTTP-Accept-Header来指示客户端要求的版本。 但是如何在我的应用程序中应用它？ 因此，有哪些变化？ 编组人员如何知道应该使用哪个版本？ 我必须注册我的类型吗？ 我所知道的是我必须更改@Produces -Annotation的内容 @GET @Path(“/locations”) @Produces(“application/vnd.mycompany-v1+xml”) Location[] getLocations(); 但还有什么必须改变？

平台强制版本控制机制是java最急需的function吗？

作为开发人员，我经常对可以让您的生活更轻松的新语言function感兴趣。 例如，java 5为该语言带来了generics和注释，这些function肯定可以提高您的工作效率。 然而，当我回顾近十年来在java平台上工作时，我发现与版本相关的问题是非生产性和不必要的努力的最大罪魁祸首。 寻找正确版本的jar的小时和小时，尝试协调一些版本冲突，升级依赖库等。当我开始使用java时，事情并不那么困难，你会有一些第三方库，就是这样。 今天，您可以轻松使用典型的Web应用程序：Spring Framework，Hibernate，Struts，您可以使用它。 所有这些都带有许多依赖的第三方库。 今天，我的耳档将通常包括大约40个或更多第三方库。 一个真正的jar子地狱！ 使用注释，我不必管理Hibernate的配置文件。 一个很好的function，但我没有看到由于我将描述符保存在单独的文件中而产生的许多问题。 使用generics，我没有编写演员语句，但在我的整个编程载体中，我记不起一个可以通过使用类型安全容器来防止的错误。 版本问题的解决方案不是更有价值吗？ 所有这些问题导致了许多工具，如Maven ， Ivy ， One Jar ， Jar Jar Links （不开玩笑！），甚至恰当地命名为Jar Hell等。即使您使用其中一些工具，您也远远不能免受问题。 我使用Maven 2，这是一个很好的帮助。 不过，它本身就是一个世界。 新手程序员可能需要一段时间来学习它。 将您的遗留项目迁移到Maven结构也很痛苦。 似乎在.Net中他们已经学会了dll地狱的教训，并且.Net程序集的管理要简单得多。 似乎有计划为java平台和像OSGI这样的替代品解决这个问题。 我认为非常需要一些基本的和平台强制的版本控制机制