Почему параметр JAX-RS пуст, когда тело сообщения нет?

#java #jersey #jax-rs

#java #джерси #jax-rs

Вопрос:

У меня есть веб-сервис JAX-RS, который я пишу, и он использует тело сообщения JSON. Проблема в том, что параметр, который должен содержать тело, всегда пуст.

 @Path("/")
public class MyClass {

    @Path("/echo")
    @PUT
    @Consumes(MediaType.APPLICATION_JSON)
    public Response echo(String message, @QueryParam("action") String action) {
        System.out.println(message);
        System.out.println(action);
        return Response.status(200).build();
    }

}
  

В этом примере действие всегда будет содержать правильное содержимое, но сообщение всегда будет пустым. Из других вопросов я пришел к выводу, что все, что необходимо для доступа к телу, — это предоставить параметр для его хранения. По независящим от меня причинам я не могу связать JSON непосредственно с объектом, как это, вероятно, лучше всего делать с to.

Мой pom.xml:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>authenticate</groupId>
  <artifactId>authenticate</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <dependencies>
    <dependency>
        <groupId>org.mongodb</groupId>
        <artifactId>mongo-java-driver</artifactId>
        <version>2.12.3</version>
    </dependency>
    <dependency>
        <groupId>com.google.code.gson</groupId>
        <artifactId>gson</artifactId>
        <version>2.8.5</version>
    </dependency>
    <dependency>
            <groupId>com.sun.jersey</groupId>
            <artifactId>jersey-server</artifactId>
            <version>1.19</version>
    </dependency>
    <dependency>
        <groupId>com.sun.jersey</groupId>
        <artifactId>jersey-servlet</artifactId>
        <version>1.19</version>
        <scope>runtime</scope>
    </dependency>
    <dependency>
        <groupId>org.glassfish.jersey.bundles</groupId>
        <artifactId>jaxrs-ri</artifactId>
        <version>2.27</version>
   </dependency>
</dependencies>
  <packaging>war</packaging>
  <build>
    <sourceDirectory>src</sourceDirectory>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.0</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
      <plugin>
        <artifactId>maven-war-plugin</artifactId>
        <version>3.2.1</version>
        <configuration>
          <warSourceDirectory>WebContent</warSourceDirectory>
          <failOnMissingWebXml>false</failOnMissingWebXml>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>
  

И мой web.xml:

 <?xml version="1.0" encoding="utf-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
  <display-name>authenticate</display-name>
  <servlet>
    <servlet-name>Jersey REST Service</servlet-name>
    <servlet-class>
    org.glassfish.jersey.servlet.ServletContainer</servlet-class>
    <init-param>
      <param-name>
      jersey.config.server.provider.packages</param-name>
      <param-value>au.com.biting.bolat</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>Jersey REST Service</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
</web-app>
  

Ответ №1:

Таким образом, проблема, по-видимому, в том, что Jersey передает содержимое только в том случае, если тип в параметре соответствует тому, что веб-служба аннотирована как способная использовать. Мое решение — просто аннотировать метод с помощью

 @Consumes
  

Вместо

 @Consumes(MediaType.APPLICATION_JSON)
  

И теперь необработанный JSON передается в строку.

Комментарии:

1. Я бы сказал, что что-то вроде MediaType.TEXT_PLAIN было бы лучше (или что бы ни отправлял Content-Type заголовок HTTP). Как есть, он примет что угодно.

2. Идея, стоящая за этим, заключалась в том, чтобы клиент мог отправлять JSON в качестве своего типа содержимого и получать фактическое содержимое в виде строки, и выполнение любой из этих вещей помешало бы мне сделать это. Я добавил немного в свой код, чтобы выдать 415, если то, что возвращается, на самом деле не JSON. Вероятно, это не лучшая практика, но для этой цели она подойдет.