¿Por qué mi servicio Spring devuelve cualquier tipo de contenido solicitado por el cliente?

Question

Tengo un servicio de descanso de primavera usando Spring 3.1.0.RELEASE. Aquí está el código relevante para el servicio de llamada en cuestión:

@RequestMapping(value="/{var1}", method=RequestMethod.GET, produces="application/json") 
@ResponseBody 
public String getSomeStuff(@PathVariable final String var1) { 
    return myJsonString; 
} 

Si llamo a esto usando el siguiente comando curl, que felizmente me devuelve mi cadena JSON con un tipo de contenido application/xml, mientras que se puede esperar una 406 basadas en la primavera 3,1 docs:

curl -v -H "Accept: application/xml" http://localhost:8080/MyServiceSite/myvalue 

no hay ninguna configuración adicional en mi aplicación para este servicio (sin serialización), Voy a volver JSON en bruto sin post-procesamiento para el servicio configurado. Estoy seguro de haberme perdido algo, ¿alguien puede señalar algo que me haya pasado por alto?

Editar: Aquí está el documentation que estaba buscando al intentar hacer que esto funcione. Específicamente la sección 16.3.2.5. Mi código es muy similar, excepto que su código parece que asume la configuración de configuración para permitir que Spring maneje la serialización. Quizás el produce no funciona al pasar por alto la serialización de primavera?

Editar: Cambié mi expectativa por el código de respuesta. Un 415 indicaría que estaba enviando contenido inapropiado en mi cuerpo de solicitud, mientras que 406 es apropiado para tener un encabezado de aceptación que no coincida con el tipo de contenido del servidor.

De todas formas, he cambiado este método, devuelvo un Mapa y agregué la configuración para serializarlo a json y ahora si envío un tipo de contenido inválido del cliente obtengo la respuesta 406 correcta. Parece que tal vez la configuración "produce" se ignora cuando la salida del método no se serializa.

Answer 1

La condición de producción es nueva en Spring MVC 3.1 y solo es compatible con RequestMappingHandlerMapping y clases de soporte de @MVC relacionadas, también new in Spring 3.1. Supongo que estás usando las clases de soporte 3.0 @MVC, que no admiten la condición produce. De lo contrario, su código es correcto y también lo son sus expectativas sobre lo que debería suceder.

El uso de encabezados = "Aceptar = aplicación/json" no es necesario en 3.1. Para eso se introdujo exactamente la condición de producción.

Answer 2

¿Qué pasa con el atributo headers para el @RequestMapping. Puede establecer el encabezado Aceptar allí. Algo como:

@RequestMapping(value="/{var1}", method=RequestMethod.GET, produces="application/json", headers = "Accept=application/json") 
@ResponseBody 
public String getSomeStuff(@PathVariable final String var1) { 
    return myJsonString; 
} 

No sé cómo Spring podría manejar una solicitud a esa ruta sin un encabezado coincidente. Si no da lo que desea, podría necesitar definir un mapeo similar sin los encabezados y hacer que devuelva una ResponseEntity y establecer el código de respuesta o algo así, pero espero que lo maneje adecuadamente.