Question

我先在stackoverflow＆amp;中进行了搜索。我无法找到与我的问题相关的任何答案。我能找到的只是与REST uri设计相关的问题。

我在后端的问题。假设我们有两个不同版本的REST uri

http://api.abc.com/rest/v1/products

http://api.abc.com/rest/v2/products

遵循后端（服务器端代码）以获得正确路由，可管理性和最佳方法的最佳方法是什么？根据版本在这两组api中重用现有的类？

我已经考虑过使用不同的@Path注释定义资源类的方法，例如有一个包v1和amp; v2单独＆amp;在该包的ProductsResource类中，定义

    package com.abc.api.rest.v1.products;
    @Path("/rest/v1/products")
    public class ProductsResource {...}

    package com.abc.api.rest.v2.products;
    @Path("/rest/v2/products")
    public class ProductsResource {...}

＆安培;然后有基于版本的实现逻辑。这种方法的问题是当我们只从api集合中改变一个特定的资源api时，我们也必须将其他类复制到v2包中。我们可以避免吗？

如何写一个自定义注释说@Version＆amp;有它支持的版本的值？现在无论是v1还是v2，两个请求都将转到相同的资源类。

比如说。

    package com.abc.api.rest.products;
    @Path("/rest/{version: [0-9]+}/products")
    @Version(1,2)
    public class ProductsResource {...}

更新

Jarrod有一个API版本控制建议来处理标题中的版本。这也是一种方法，但我期待在遵循基于URI的版本控制时使用最佳实践

Answer 1

将其放入URL中的问题是URL应该按位置表示资源。 API Version不是位置，也不是资源标识符的一部分。

在网址中粘贴/v2/会破坏之前的所有现有链接。

有一种正确的方法可以指定API版本：

将其放在您想要的Accept:标头的mime-type中。像Accept: application/myapp.2.0.1+json

这样的东西

Chain of Responsiblity模式在这里很顺利，特别是如果有大量API版本不同，必须拥有自己的处理程序，这样方法就不会失控。

Answer 2

这篇博客文章中有一些例子被认为是正确的方法，即URI中没有版本：http://codebias.blogspot.ca/2014/03/versioning-rest-apis-with-custom-accept.html

简而言之，它利用JAX-RS @Consume注释将特定版本的请求与特定实现相关联，如：

@Consumes({"application/vnd.blog.v1+xml", "application/vnd.blog.v1+json"})

Answer 3

我只是想知道为什么没有ProductService的子类叫

@Path(/v2/ProductService)
ProductServiceV2 extends ProductService {


}


@Path(/v1/ProductService)
 class ProductService{


}

并且只覆盖v2中更改的内容。所有未更改的内容与v1 / ProductService中的相同。

这种defintely导致了更多的类，但是只有一种更简单的方法来编码新版api中的任何变化，并且在没有重复代码的情况下恢复到旧版本。

处理JAX-RS REST API URI版本控制的最佳方法

3 个答案: