我们的Java EE项目有一个RESTful接口,类似于http://example.com/rest/
。当开发进展时,我们创建此接口的新版本。为了实现向后兼容性,我们希望在不同的URL上在线提供它们,例如:
http://example.com/rest/1.0/
http://example.com/rest/1.1/
问题是如何部署它们?我们应该组装一些WAR(我们使用Maven)吗?但该项目在/trunk
中有最新版本。也许我们应该通过一些Maven插件将它们全部打包到一个WAR中,从Subversion /tags
中检索它们?你有什么经历?
答案 0 :(得分:4)
当我用锤子敲击手指时会疼,我该怎么办?别打了吗?
REST架构风格的主要目标之一是允许客户端和服务器独立发展。
通过创建新版本的服务,您实际上创建了一个全新的服务来替换旧服务。通过这样做,你扔掉了REST试图实现的目标。
也许你打算简单地构建一个HTTP Api,在这种情况下,继续。 (但是在版本控制时不要抱怨: - ))
如果您确实想要执行REST,那么请认识到如果您发现自己需要对REST API进行版本修改,那么您就会做错了。这可能发生,如果确实如此,我建议首先要考虑版本化媒体类型。版本控制URI是最后的手段。
答案 1 :(得分:2)
它们都是您应用程序的“一流”部分。
不要将它们分开。你只会在尝试更新一个而不触及另一个时感到困惑。
当你做出改变时,你可能不得不释放一切。
答案 2 :(得分:1)
使用不同的路径部署不同的战争到接口类。这样你可以删除“旧”版本而不会打扰新版本。我个人总是以新的文件名部署新版本。这样你就不必关心任何旧文件了。
答案 3 :(得分:1)
如果通过版本控制,您谈论的是资源/内容类型的结构,则必须保留旧的实现并使用content negotiation,以便旧版客户端仍然可以使用您的服务。
如果唯一的更改是在网址结构上,那么您不需要任何版本控制,只需使用301-Moved Permanently重定向。