Java Restful的标头中的API版本控制服务

全部

我正在检查Rest头中版本API的服务，我正在使用Java语言和Jersey框架。所有请求（POST、GET、PUT和DELETE）中都没有仅URI的头。请参见下面的示例

例如： 获取/雇用

---

Header-Version:1.0在REST的面向资源的体系结构样式下，您将对资源本身进行版本设置，而不是对服务进行版本设置。您可以通过使用自定义的、版本化的媒体类型来实现这一点。例如，使用Java和JAX-RS，它可能看起来像这样：

@Path("/resource/account/{id}")
@GET
@Produces("application/vnd.mycompany.account-1.0+json")
public Response getAccount(@PathParam("id") String id) {
    ...

@Path("/resource/account")
public class AccountWebService {

    @GET
    @Path("/{id}")
    @Produces("application/vnd.mycompany.account-1.0+json")
    public Response getAccount(@PathParam("id") String id) {
    ...

    @GET
    @Path("/{id}")
    @Produces("application/vnd.mycompany.account-2.0+json")
    public Response getAccountV2(@PathParam("id") String id) {
    ...

请注意@products注释中媒体类型字符串中的版本号

然后，在客户端中，当您发出请求时，您可以使用Accept标头指定您想要给定的媒体类型：

Accept: application/vnd.mycompany.account-1.0+json

换句话说，不要这样做：

@Path("/resource/account/v1/{id}")

如果要支持多个版本，则服务类可能如下所示：

@Path("/resource/account/{id}")
@GET
@Produces("application/vnd.mycompany.account-1.0+json")
public Response getAccount(@PathParam("id") String id) {
    ...

@Path("/resource/account")
public class AccountWebService {

    @GET
    @Path("/{id}")
    @Produces("application/vnd.mycompany.account-1.0+json")
    public Response getAccount(@PathParam("id") String id) {
    ...

    @GET
    @Path("/{id}")
    @Produces("application/vnd.mycompany.account-2.0+json")
    public Response getAccountV2(@PathParam("id") String id) {
    ...

---

我们通常将媒体类型拉入公共静态，以便从测试客户端访问和使用它们。在单元测试中，一定要使用来测试您的web服务。

您的问题不清楚-您想做什么？您正在尝试实现版本控制吗？如果我想在restful中的版本头中传递值，也可以在版本头中接收响应。GET cars？color=blue Content Type:application/json Accept:application/json Version:1.0我只需要标题，所以我将值传递到版本标题中，并在其余部分的版本标题中接收结果。没有URI。示例：GET cars？color=blue Content Type:application/json Accept:application/json Version:1.0JAX-RS有一个HeaderParam注释，您使用它就像PathParam或QueryParamOne一样，但这是您的方法的一个主要问题，就是你必须在你的服务中实现一个方法来处理所有的版本，而不是将不同的版本映射到不同的方法。正如Russ所说，使用这种方法你不能有两个具有相同路径的不同方法。资源方法选择不基于@products标头。因此，您必须在单个方法中实现这一点。将路径作为资源URL的一部分在打包和分发方面提供了更大的灵活性。您可以为同一服务的不同版本提供不同的资源类，这些服务可能打包在单独WAR/EAR的同一WAR/EAR中。