BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Java RESTful Web Service实战

| 作者 韩陆 关注 11 他的粉丝 发布于 2016年8月21日. 估计阅读时间: 56 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

编者按: InfoQ开设栏目“品味书香”,精选技术书籍的精彩章节,以及分享看完书留下的思考和收获,欢迎大家关注。本文节选自韩陆著《Java RESTful Web Service实战》中的章节“REST API 设计”,介绍REST请求流程等内容。

3.3 REST请求流程

从REST请求处理的扩展点上,我们已经讲述了用于实体处理的Provider接口以及上下文处理和异常处理的Provider。本章还将讲述两种在面向切面编程中非常重要的特殊Provider:过滤器(3.4节)和拦截器(3.5节)。在进入这个主题之前,我们需要对REST请求处理的流程这条线有明确的认识,如图3-5所示,这样以来,才会知道这些点都处于流程的什么位置。只有这样才能清楚地实现对扩展点的开发和调试。

在图3-5中,请求流程中存在3种角色,分别是用户、REST客户端和REST服务器。请求始于请求的发送,止于调用Response类的readeEntity()方法,获取响应实体。

1)用户提交请求数据,客户端接收请求,进入第一个扩展点:“客户端请求过滤器ClientRequestFilter实现类”的filter()方法。

2)请求过滤处理完毕后,流程进入第二个扩展点:“客户端写拦截器WriterInterceptor实现类”的aroundWriteTo()方法,实现对客户端序列化操作的拦截。

3)“客户端消息体写处理器MessageBodyWriter”执行序列化,流程从客户端过渡到服务器端。

4)服务器接收请求,流程进入第三个扩展点:“服务器前置请求过滤器Container-RequestFilter实现类”的filter()方法。

图3-5 Jersey的REST请求处理流程

5)过滤处理完毕后,服务器根据请求匹配资源方法,如果匹配到相应的资源方法,流程进入第四个扩展点:“服务器后置请求过滤器ContainerRequestFilter实现类”的filter()方法。

6)后置请求过滤处理完毕后,流程进入第五个扩展点:“服务器读拦截器ReaderInterceptor实现类”的aroundReadFrom()方法,拦截服务器端反序列化操作。

7)“服务器消息体读处理器MessageBodyReader”完成对客户端数据流的反序列化。服务器执行匹配的资源方法。

8)REST请求资源的处理完毕后,流程进入第六个扩展点:“服务器响应过滤器ContainerResponseFilter实现类”的filter()方法。

9)过滤处理完毕后,流程进入第七个扩展点:“服务器写拦截器WriterInterceptor实现类”的aroundWriteTo()方法,对服务器端序列化到客户端这个操作的拦截。

10)“服务器消息体写处理器MessageBodyWriter”执行序列化,流程返回到客户端一侧。

11)客户端接收响应,流程进入第八个扩展点:“客户端响应过滤器Client-ResponseFilter实现类”的filter()方法。

12)过滤处理完毕后,客户端响应实例response返回到用户一侧,用户执行response.readEntity()流程进入第九个扩展点:“客户端读拦截器ReaderInterceptor实现类”的aroundReadFrom()方法,对客户端反序列化进行拦截。

13)“客户端消息体读处理器MessageBodyReader”执行反序列化,将Java类型的对象最终作为readEntity()方法的返回值。到此,一次REST请求处理的完整流程完毕。这期间,如果出现异常或资源不匹配等情况,会从出错点开始结束流程。

3.4 REST过滤器

从上一节的流程讲述中,我们了解JAX-RS2定义的4种过滤器扩展点(Extension Point)接口,供开发者实现业务逻辑,按请求处理流程的先后顺序为:客户端请求过滤器(ClientRequestFilter)->服务器请求过滤器(ContainerRequestFilter)->服务器响应过滤器(ContainerResponseFilter)->客户端响应过滤器(ClientResponseFilter)。本节将全面讲述4种过滤器的使用。

3.4.1 ClientRequestFilter

客户端请求过滤器(ClientRequestFilter)定义的过滤方法filter()包含一个输入参数,是客户端请求的上下文类ClientRequestContext。从该上下文中可以获取请求信息,典型的示例包括获取请求方法context.getMethod(),获取请求资源地址context.getUri()和获取请求头信息context.getHeaders()等。过滤器的实现类中可以利用这些信息,覆写该方法以实现该类特有的过滤功能。ClientRequestFilter接口的实现类如图3-6所示。

图3-6 ClientRequestFilter接口的实现类

图3-6展所示了ClientRequestFilter接口的实现类,包括Jersey内部提供的实现类和本书示例代码中的实现类。我们选择HTTP认证过滤器类HttpAuthenticationFilter作为例子,来感受上面的讲述,(HTTP基本认证的内容请参考10.1节。)示例代码如下所示。

@Override
public void filter(ClientRequestContext request) throws IOException {
  if(!"true".equals(request.getProperty("org.glassfish.jersey.client.authentication.HttpAuthenticationFilter.reused"))) {
    if(!request.getHeaders().containsKey("Authorization")) {
      HttpAuthenticationFilter.Type operation = null;
      if(this.mode == Mode.BASIC_PREEMPTIVE) {
        this.basicAuth.filterRequest(request);
        operation = HttpAuthenticationFilter.Type.BASIC;
...
      if(operation != null) {
        request.setProperty("org.glassfish.jersey.client.authentication.HttpAuthenticationFilter.operation", operation);
      }

在这段代码中,HTTP基本认证过滤器类在filter()方法中,判断请求头信息中是否包含"Authorization",如果不包含则通过filterRequest()方法添加请求头"Authorization"为authentication,authentication的内容是"Basic" + Base64.encodeAsString(usernamePassword)。这样以来,经过HTTP基本认证过滤器类过滤处理后,可以确保请求头信息中包含"Authorization"。

3.4.2 ContainerRequestFilter

针对过滤切面,服务器请求过滤器接口ContainerRequestFilter的实现类可以定义为预处理和后处理。默认情况下,采用后处理方式。即先执行容器接收请求操作,当服务器接收并处理请求后,流程才进入过滤器实现类的filter()方法。而预处理是在服务器处理接收到的请求之前就执行过滤。如果希望实现一个预处理的过滤器实现类,需要在类名上定义注解@PreMatching。

服务器请求过滤器定义的过滤方法filter()包含一个输入参数,即容器请求上下文类ContainerRequestContext。ContainerRequestFilter接口的实现类,如图3-7所示。

图3-7 ContainerRequestFilter接口的实现类

图3-7展示了ContainerRequestFilter接口的实现类,我们以CsrfProtectionFilter为例来说明,示例代码如下所示。

package org.glassfish.jersey.server.filter;

@Priority(Priorities.AUTHENTICATION) //post-matching 
public class CsrfProtectionFilter implements ContainerRequestFilter {
  public static final String HEADER_NAME = "X-Requested-By";
  //关注点1 忽略方法集合 
  private static final Set<String> METHODS_TO_IGNORE;
  static {
    HashSet<String> mti = new HashSet<>();
    mti.add("GET");
    mti.add("OPTIONS");
    mti.add("HEAD");
    METHODS_TO_IGNORE = Collections.unmodifiableSet(mti);
  }

  @Override
  public void filter(ContainerRequestContext rc) throws IOException {
      //关注点2 判断方法名称是否符合条件 
    if (!METHODS_TO_IGNORE.contains(rc.getMethod()) && !rc.getHeaders().containsKey(HEADER_NAME)) {
        throw new BadRequestException();
    }
  }
}

在这段代码中,CsrfProtectionFilter定义了一个特殊的头信息"X-Requested-By"和CSRF忽略监控的方法集合,见关注点1。在过滤器的filter()方法中,首先从上下文中获取头信息rc.getHeaders()和请求方法信息rc.getMethod(),然后判断头信息是否包含"X-Requested-By",方法信息是否是安全的请求方法,即"GET"、"OPTIONS"或"HEAD"。如果两个条件都不成立,过滤器会抛出一个运行时异常BadRequestException,见关注点2。通过CsrfProtectionFilter过滤器,可以确保请求是CSRF安全的。

阅读指南

CsrfProtectionFilter类使用了注解@Priority(Priorities.AUTHENTICATION)来定义该类,明确了该过滤器具有最高的优先级。同时,以注解的文字告诉开发者,需要将其放在过滤器链的第一个位置。因此,在定义和使用过滤器时,需要考虑运行中过滤器的执行先后顺序,否则无法实现过滤器的功能或者使流程混乱。

3.4.3 ContainerResponseFilter

服务器响应过滤器接口ContainerResponseFilter定义的过滤方法filter()包含两个输入参数,一个是容器请求上下文类ContainerRequestContext,另一个是容器响应上下文类ContainerResponseContext。ContainerResponseFilter接口的实现类如图3-8所示。

图3-8 ContainerResponseFilter接口的实现类

图3-8展示了ContainerResponseFilter接口的实现类,我们以EncodingFilter为例来说明。该过滤器的作用是完成内容协商中编码匹配的工作(内容协商这个知识点请参考3.6节),示例代码如下所示。

@Priority(Priorities.HEADER_DECORATOR)
public final class EncodingFilter implements ContainerResponseFilter {
    @Override
    public void filter(ContainerRequestContext request, ContainerResponseContext response) throws IOException {
...
      List<String> varyHeader = ((ContainerResponse) response).getStringHeaders().get(HttpHeaders.VARY);
      //关注点1:Vary头信息 
      if (varyHeader == null || !varyHeader.contains(HttpHeaders.ACCEPT_ENCODING)) {
        response.getHeaders().add(HttpHeaders.VARY, HttpHeaders.ACCEPT_ENCODING);
      }
...
      //关注点1:Content-Encoding头信息 
      if (!IDENTITY_ENCODING.equals(contentEncoding)) {
        response.getHeaders().putSingle(HttpHeaders.CONTENT_ENCODING, contentEncoding);
      }
    }

EncodingFilter过滤器的filter()方法通过对请求头信息“Accept-Encoding”的分析,先后为响应头信息“Vary”和“Content-Encoding”赋值,以实现编码部分的内容协商。见关注点1。

3.4.4 ClientResponseFilter

客户端响应过滤器(ClientResponseFilter)定义的过滤方法filter()包含两个输入参数,一个是客户端请求的上下文类ClientRequestContext,另一个是客户端响应的上下文类ClientResponseContext。ClientResponseFilter接口的实现类,如图3-9所示。

图3-9 ClientResponseFilter接口的实现类

图3-9展示了ClientResponseFilter接口的实现类,包括Jersey内部提供的实现类和本书示例代码中的实现类。我们以HTTP摘要认证过滤器类HttpAuthenticationFilter为例进行演示,(HTTP摘要认证请参考10.1节。)示例代码如下所示。

@Override
public void filter(ClientRequestContext request, ClientResponseContext response) throws IOException {
...
    if(response.getStatus() == Status.UNAUTHORIZED.getStatusCode()) {
    String operation = (String)response.getHeaders().getFirst("WWW-Authenticate");
    if(operation != null) {
      String success = operation.trim().toUpperCase();
      if(success.startsWith("BASIC")) {
          result = HttpAuthenticationFilter.Type.BASIC;
      } else {
        if(!success.startsWith("DIGEST")) {
          return;
        }
        result = HttpAuthenticationFilter.Type.DIGEST;
      }
    }
    authenticate = true;
    } else {
    authenticate = false;
    }

    if(this.mode != Mode.BASIC_PREEMPTIVE) {
    if(this.mode == Mode.BASIC_NON_PREEMPTIVE) {
      if(authenticate && result == HttpAuthenticationFilter.Type.BASIC) {
        this.basicAuth.filterResponseAndAuthenticate(request, response);
      }
    } else if(this.mode == Mode.DIGEST) {
      if(authenticate && result == HttpAuthenticationFilter.Type.DIGEST) {
        this.digestAuth.filterResponse(request, response);
      }
    }
    ...
    }

3.4.5 访问日志

3.4.1〜3.4.5节完成了对JAX-RS2定义的4种过滤器的讲述,本节利用上述知识,演示如何综合运用过滤器,完成一个记录REST请求的访问日志。

1.访问日志实现类

访问日志类AirLogFilter实现了上述的4种过滤器,旨在记录服务器和客户端的请求和响应运行时的信息。AirLogFilter类定义如下所示。

@PreMatching
public class AirLogFilter implements ContainerRequestFilter, ClientRequestFilter,
ContainerResponseFilter, ClientResponseFilter {

AirLogFilter为每一种过滤器接口定义的filter()方法提供了实现。在客户端请求过滤中,输出请求资源地址信息和请求头信息;在容器请求过滤中,输出请求方法、请求资源地址信息和请求头信息;在容器响应过滤中,输出HTTP状态码和请求头信息;在客户端响应过滤中,输出HTTP状态码和请求头信息。4个阶段的filter()示例代码如下所示。

@Override 
public void filter(ClientRequestContext context) throws
IOException {
    long id = logSequence.incrementAndGet();
    StringBuilder b = new StringBuilder();
    //关注点1:获取请求方法和地址 
    printRequestLine(CLIENT_REQUEST, b, id, context.getMethod(), context.getUri());
    //关注点2:获取请求头信息 
    printPrefixedHeaders(CLIENT_REQUEST, b, id, HeadersFactory.asStringHeaders (context.getHeaders()));
    LOGGER.info(b.toString()); }

在这段代码中,AirLogFilter类实现了客户端响应过滤。从客户端响应上下文实例中,可以获取到响应状态信息和响应头信息。分别见关注点1和关注点2。

@Override
public void filter(ContainerRequestContext context) throws IOException {
    long id = logSequence.incrementAndGet();
    StringBuilder b = new StringBuilder();
    //关注点1:获取容器请求方法和请求地址信息 
    printRequestLine(SERVER_REQUEST, b, id, context.getMethod(), context.getUriInfo().getRequestUri());
    //关注点2:获取请求头信息 
    printPrefixedHeaders(SERVER_REQUEST, b, id, context.getHeaders());
    LOGGER.info(b.toString());
}

在这段代码中,AirLogFilter类实现了容器请求过滤。从容器请求上下文实例中,可以获取到请求方法和请求资源地址信息,见关注点1。同样,可以从中获取请求头信息,见关注点2。

@Override
public void filter(ContainerRequestContext requestContext,
ContainerResponseContext responseContext) throws IOException {
    long id = logSequence.incrementAndGet();
    StringBuilder b = new StringBuilder();
    //关注点1:获取容器响应状态 
    printResponseLine(SERVER_RESPONSE, b, id, responseContext.getStatus());
    //关注点2:获取容器响应头信息 
    printPrefixedHeaders(SERVER_RESPONSE, b, id, HeadersFactory.asStringHeaders(responseContext.getHeaders()));
    LOGGER.info(b.toString());
}

在这段代码中,AirLogFilter类实现了容器响应过滤。从容器响应上下文实例中,可以获取到容器的响应状态信息和响应头信息。分别见关注点1和关注点2。 2. 单元测试类

访问日志的单元测试示例如下所示。

public class TIResourceJtfTest extends JerseyTest {
    @Override
    protected Application configure() {
        ResourceConfig config = new ResourceConfig(BookResource.class);
        return config.register(com.example.filter.log.AirLogFilter.class);
    }
    @Override
    protected void configureClient(ClientConfig config) {
        config.register(new AirLogFilter());
    }

在这段代码中,为了使访问日志类生效,需要测试类TIResourceJtfTest在Jersey测试框架的服务器端和客户端,分别注册服务日志类AirLogFilter。 单元测试的结果如下所示,在4种过滤器中分别打印了该阶段的日志信息。

main - 1 * AirLog - Request received on thread main
1 / GET http://localhost:9998/books/1
1 / Accept: application/json
Grizzly-worker(1) - 2 * AirLog - Request received on thread Grizzly-worker(1)
2 > GET http://localhost:9998/books/1
2 > accept: application/json
...
Grizzly-worker(1) - 3 * AirLog - Response received on thread Grizzly-worker(1)
3 < 200
3 < Content-Type: application/json
main - 4 * AirLog - Response received on thread main
4 \ 200
4 \ Content-Type: application/json
...

3.5 REST拦截器

拦截器和过滤器的相同点是都是一种在请求—响应模型中,用做切面处理的Provider。两者的不同除了功能性上的差异(一个用于过滤消息,一个用于拦截处理)之外,形式上也不同。拦截器通常读写成对,而且没有服务器端和客户端的区分。Jersey提供的拦截器类,如图3-10所示。

图3-10 读写拦截器的实现类

在图3-10中,Jersey内部实现了几个典型应用的拦截器,它们是成对出现的。比如GZiPEncoder同时实现了读写拦截器,以实现使用GZip压缩格式压缩消息体的功能。

1. ReaderInterceptor

读拦截器接口ReaderInterceptor定义的拦截方法是aroundReadFrom(),该方法包含一个输入参数,即读拦截器的上下文接口ReaderInterceptorContext,从中可以获取头信息、输入流以及父接口InterceptorContext提供的媒体类型等上下文信息。接口方法示例如下。

public Object aroundReadFrom(ReaderInterceptorContext context) throws java.io.IOException, javax.ws.rs.WebApplicationException;

2. WriterInterceptor

写拦截器接口WriterInterceptor定义的拦截方法是aroundWriteTo(),该方法包含一个输入参数,写拦截器上下文接口WriterInterceptorContext,从中可以获取头信息、输出流以及父接口InterceptorContext提供的媒体类型等上下文信息。接口方法示例如下所示。

void aroundWriteTo(WriterInterceptorContext context) throws java.io.IOException, javax.ws.rs.WebApplicationException;

3. 编解码约束拦截器

编解码约束拦截器类ContentEncoder是一个位于org.glassfish.jersey.spi包中的拦截器,SPI包下的工具是可插拔的。ContentEncoder拦截器用于约束序列化和反序列化的过程中,编解码的内容协商,示例代码如下所示。

@Override
public final Object aroundReadFrom(ReaderInterceptorContext context)
throws IOException, WebApplicationException {
    String contentEncoding = context.getHeaders().getFirst(HttpHeaders.CONTENT_ENCODING);
    //关注点1:判断是否包含Content-Encoding头信息 
    if (contentEncoding != null && getSupportedEncodings().contains(contentEncoding)) {
    //关注点2:解码处理 
        context.setInputStream(decode(contentEncoding, context.getInputStream()));
    }
    //关注点3:继续拦截链的下一个拦截处理 
    return context.proceed();
}

@Override
public final void aroundWriteTo(WriterInterceptorContext context)
throws IOException, WebApplicationException {
    String contentEncoding = (String) context.getHeaders().getFirst (HttpHeaders.CONTENT_ENCODING);
    //关注点1:判断是否包含Content-Encoding头信息 
    if (contentEncoding != null && getSupportedEncodings().contains (contentEncoding)){
    //关注点2:编码处理 
        context.setOutputStream(encode(contentEncoding, context.getOutputStream()));
    }
    //关注点3:继续拦截链的下一个拦截处理 
    context.proceed();
}

在这段代码中,分别给出了ContentEncoder拦截器的读、写拦截处理,只有当头信息包含“Content-Encoding”信息,编解码才被执行,见关注点1。读取阶段进行解码,写入阶段进行编码,见关注点2。上下文的proceed()方法用于执行拦截器链的下一个拦截器,见关注点3。

3.6 绑定机制

在我们了解了面向切面的Providers的功能后,需要掌握它们是如何加载的,以及其作用域。这些容器级别的Providers,通常使用编码的方式注册到Application中,但这不是唯一的办法。本节将详细讨论Providers的绑定机制。 默认情况下,过滤器和拦截器都是全局绑定的。也就是说,如下之一的过滤器或拦截器是全局有效的。

  • 通过手动注册到Application或者Configuration;
  • 注解为@Provider,被自动探测。

下面介绍其他的绑定机制。

3.6.1 名称绑定

过滤器或拦截器可以使用特定的注解来指定其作用范围,这种特定的注解被称为名称绑定。

1. 名称绑定注解

使用@NameBinding注解可以定义一个运行时的自定义注解,该注解用于定义类级别名称和类的方法名,代码示例如下所示。

@NameBinding
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(value = RetentionPolicy.RUNTIME)
public @interface AirLog {
}

在这段代码中,自定义注解AirLog使用了@NameBinding,在运行时该注解将被解析为一个名称绑定的注解。

2. 绑定Provider

在定义了@AirLog注解后,既可以在Provider中使用该注解,示例代码如下所示。

//关注点1:使用自定义注解@AirLog 
@AirLog
@Priority(Priorities.USER)
public class AirNameBindingFilter implements ContainerRequestFilter, ContainerResponseFilter {
  private static final Logger LOGGER = Logger.getLogger(AirNameBindingFilter.class);
  public AirNameBindingFilter() {
    LOGGER.info("Air-NameBinding-Filter initialized");
  }
  @Override
  //关注点2:filter实现访问日志 
  public void filter(final ContainerRequestContext containerRequest) throws IOException {
    LOGGER.debug("Air-NameBinding-ContainerRequestFilter invoked:" +
    containerRequest.getMethod());
    LOGGER.debug(containerRequest.getUriInfo().getRequestUri());
  }
  @Override
  //关注点3:filter实现访问日志 
  public void filter(ContainerRequestContext containerRequest,
  ContainerResponseContext responseContext) throws IOException {
    LOGGER.debug("Air-NameBinding-ContainerResponseFilter invoked:" +
    containerRequest.getMethod());
    LOGGER.debug("status=" + responseContext.getStatus());
  }
}

在这段代码中,过滤器类AirNameBindingFilter使用了自定义注解@AirLog,这样AirNameBindingFilter类就实现了名称绑定,见关注点1。该类实现了容器的请求和响应过滤器接口,功能是记录访问日志,见关注点2。

3. 绑定方法

接下来,我们在资源方法级别使用自定义注解@AirLog,来实现在资源类的指定方法上启用AirNameBindingFilter过滤器,示例代码如下所示。

@Path("books")
public class BookResource {
  //关注点1:绑定方法 
  @AirLog
  @GET
  @Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
  public Books getBooks() {
...
    return books;
  }
...

在这段代码中,资源类BookResource包含多个方法,我们只在getBooks()方法上使用了注解@AirLog,而其他方法并没有绑定,见关注点1。

4. 单元测试类

接下来,通过单元测试来校验名称绑定的设计和实现是否正确,示例代码如下所示。

public class TestNamingBinding extends JerseyTest {
    @Override
    protected Application configure() {
    //关注点1:AirAopConfig内部注册了AirNameBindingFilter 
    return new AirAopConfig();
    }
    @Test
    //关注点2:测试getBookByPath()方法 
    public void testPathGetJSON() {
        final WebTarget pathTarget = target(BASE_URI).path("1");
        final Invocation.Builder invocationBuilder = pathTarget.request (MediaType.APPLICATION_JSON_TYPE);
        final Book result = invocationBuilder.get(Book.class);
        Assert.assertNotNull(result.getBookId());
    }
    @Test
    //关注点3:测试getBooks()方法 
    public void testGetAll() {
        final Invocation.Builder invocationBuilder = target(BASE_URI).request();
        final Books result = invocationBuilder.get(Books.class);
        Assert.assertNotNull(result.getBookList());
    }
}

在这段代码中,测试类TestNamingBinding通过AirAopConfig注册了AirNameBindingFilter过滤器,见关注点1。该类包含两个测试方法,分别是测试资源类BookResource的getBooks()和getBookByPath()两个方法,见关注点2和关注点3。

我们可以从终端打印的信息来检验名称绑定的运行结果,示例如下。

Air-NameBinding-ContainerRequestFilter invoked:GET
http://localhost:9998/books/
Air-NameBinding-ContainerResponseFilter invoked:GET
status=200

从上述测试结果中可以看到,只有在testGetAll()方法输出的日志中输出了AirNameBindingFilter类中定义的日志信息。这和预期的“只有使用注解@AirLog定义的方法,才会在请求流程中启用相应的Provider”一致。

3.6.2 动态绑定

名称绑定需要通过自定义的注解名称来绑定Provider和扩展点方法或者类,相比而言,动态绑定无须新增注解,而是使用编码的方式,实现动态特征接口javax.ws.rs.container.DynamicFeature,定义扩展点方法的名称、请求方法类型等匹配信息。在运行期,一旦Provider匹配当前处理类或方法,面向切面的Provider方法即被触发。

1. 定义绑定Provider

AirDynamicFeature类实现了DynamicFeature接口,示例代码如下。
public class AirDynamicFeature implements DynamicFeature {
  @Override
  public void configure(final ResourceInfo resourceInfo, final FeatureContext context) {
    boolean classMatched = BookResource.class.isAssignableFrom(resourceInfo.getResourceClass());
    boolean methodNameMatched = resourceInfo.getResourceMethod().getName().contains("getBookBy");
    boolean methodTypeMatched = resourceInfo.getResourceMethod().isAnnotationPresent(POST.class);
    //关注点1:匹配成功才注册AirDynamicBindingFilter 
    if (classMatched &&(methodNameMatched || methodTypeMatched)) {
      context.register(AirDynamicBindingFilter.class);
    }
  }
}
public class AirDynamicBindingFilter implements ContainerRequestFilter {
  @Override
  public void filter(final ContainerRequestContext requestContext) throws IOException {
    AirDynamicBindingFilter.LOGGER.debug("Air-Dynamic-Binding-Filter invoked");
  }
}

在这段代码中,在AirDynamicFeature的配置方法中,启用了如下匹配规则。

1)类匹配:对BookResource类及其子类的匹配。 2)方法名称匹配:方法名包含getBookBy()的匹配。 3)请求方法类型匹配:与POST方法的匹配。

只有当匹配成功时,才会注册AirDynamicBindingFilter。对于Provider的实现类,并没有特殊的要求。

2. 单元测试类

测试类TestDynamicBinding注册了动态绑定特征实现类AirDynamicFeature,示例代码如下所示。

    public class TestDynamicBinding extends JerseyTest {
      @Override
      protected Application configure() {
        ResourceConfig config = new ResourceConfig(BookResource.class);
        config.register(AirDynamicFeature.class);
        return config;
      }
     
      @Test
      public void testPost() {
        final Book newBook = new Book("Java Restful Web Service使用指南-" + System.nanoTime());
        final Entity<Book> bookEntity = Entity.entity(newBook, MediaType.APPLICATION_JSON_TYPE);
        final Book savedBook = target(BASE_URI).request(MediaType.APPLICATION_JSON_TYPE).post(bookEntity, Book.class);
        Assert.assertNotNull(savedBook.getBookId());
      }
    }

运行测试方法,AirDynamicBindingFilter的日志信息如预期输出,示例代码如下所示。

Air-Dynamic-Binding-Filter initialized
Air-Dynamic-Binding-Filter invoked

书籍介绍

本书系统、深度讲解了如何基于Java标准规范实现REST风格的Web服务,由拥有10余年开发经验的阿里云大数据架构师撰写,第1版上市后广获赞誉,成为该领域的畅销书。第2版对全书进行了优化和重构,不仅根据新的技术版本对原有过时内容进行了更新,而且还根据整个技术领域的发展增添了新的内容。除此之外,还对第1版中存在的不足进行了优化,使得内容更加与时具进、更加有价值。不仅深刻解读了新的JAX-RS标准和其API设计,以及Jersey的使用要点和实现原理,还系统讲解了REST的基本理论,更重要的是从实践角度深度讲解了如何基于Jersey实现完整的、安全的、高性能的REST式的Web服务,书中包含大量示例代码,实战性强。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT