llamada jquery ajax rest - Tipo de medio no admitido

Question

Tengo una llamada jquery ajax simple a un servicio de descanso. Estoy configurando contentType como "application/json" y el resto del recurso está configurado para aceptar "MediaType.APPLICATION_JSON". Este es un método POST. Con esta configuración, aparece el mensaje "Tipo de medio no admitido".

La información de la cabecera muestra "aplicación Content-Type/JSON; charset = UTF-8" en el encabezado de la solicitud

Respuesta muestra: Informe de estado: se admite el tipo de medios El servidor rechazó esta solicitud porque la entidad de solicitud está en un formato no compatible con el recurso solicitado para el método solicitado (Tipo de medio no admitido).

Proporcione algunos consejos para resolver este problema.

Aquí es el fragmento de código:

Recursos Resto

@POST 
@Produces({MediaType.APPLICATION_JSON,MediaType.TEXT_HTML}) 
@Consumes({MediaType.APPLICATION_JSON,MediaType.TEXT_HTML}) 
public Response addPerson(MyJSONObj myObj) { 
    //... 
    // ... 
    //... 
} 

jQuery

$(document).ready(function() { /* put your stuff here */ 
    $("#Button_save").click(function(){ 
    var firstName = $('firstName').val(); 
    var lastName = $('lastName').val(); 
    var person = {firstName: firstName, lastName: lastName}; 
    $.ajax({ 

     url:'http://localhost:8080/sampleApplication/resources/personRestService/', 
     type: 'POST', 
     data: person, 
     Accept : "application/json", 
     contentType: "application/json", 

     success:function(res){ 
     alert("it works!"); 
     }, 
     error:function(res){ 
      alert("Bad thing happend! " + res.statusText); 
     } 
    }); 
    }); 
}); 

encabezados como se muestra en FF Firebug

encabezados de respuesta

Content-Length 1117 
Content-Type text/html;charset=utf-8 
Date Thu, 05 Apr 2012 09:44:45 GMT 
Server Apache-Coyote/1.1 

cabeceras de solicitud

Accept */* 
Accept-Encoding gzip, deflate 
Accept-Language en-us,en;q=0.5 
Connection keep-alive 
Content-Length 97 
Content-Type application/json; charset=UTF-8 
Host localhost:8080 
Referer http://localhost:8080/sampleApplication/ 
User-Agent Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0 
X-Requested-With XMLHttpRequest 

Answer 1

Parece que puede estar sufriendo de una abstracción con fugas. Ver esta respuesta: JQuery's getJSON() not setting Accept header correctly?

Si está realizando una llamada entre dominios, parece que no puede establecer el encabezado de aceptación debido a la forma en que jQuery resuelve la llamada de usted.

Sin embargo, dices que el servidor ve el encabezado de aceptar correcto. Eso podría estar indicando un problema diferente.

Answer 2

tuve el mismo problema y yo era capaz de resolver de esa manera (ver http://www.weverwijk.net/wordpress/tag/jquery/):

$.ajax({ 
    url:'http://localhost:8080/sampleApplication/resources/personRestService/', 
    type:'POST', 
    data: JSON.stringify(person), 
    dataType: 'json', 
    contentType: "application/json; charset=utf-8", 
    success:function(res){ 
     alert("it works!"); 
    }, 
    error:function(res){ 
     alert("Bad thing happend! " + res.statusText); 
    } 
}); 

Por el lado de Java añadí estos (ver Access-Control-Allow-Origin):

@OPTIONS 
public Response testt(@Context HttpServletResponse serverResponse) { 
    serverResponse.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS, HEAD"); 
    serverResponse.addHeader("Access-Control-Allow-Credentials", "true"); 
    serverResponse.addHeader("Access-Control-Allow-Origin", "*"); 
    serverResponse.addHeader("Access-Control-Allow-Headers", "Content-Type,X-Requested-With"); 
    serverResponse.addHeader("Access-Control-Max-Age", "60"); 
    return Response.ok().build(); 
} 

@POST 
@Produces(MediaType.APPLICATION_JSON) 
@Consumes(APPLICATION_JSON) 
public Response addPerson(MyJSONObj myObj, @Context HttpServletResponse serverResponse) 
    serverResponse.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS, HEAD"); 
    serverResponse.addHeader("Access-Control-Allow-Credentials", "true"); 
    serverResponse.addHeader("Access-Control-Allow-Origin", "*"); 
    serverResponse.addHeader("Access-Control-Allow-Headers", "Content-Type,X-Requested-With"); 
    serverResponse.addHeader("Access-Control-Max-Age", "60"); 

    // ... 
    // ... 
} 

Conclusión

• JSON Objeto se transfiere y transformado automágicamente (más detalles ver Configuring JSON for RESTful Web Services)
• POSTAL cometer
• entre dominios (mismo origen-Política)
• Firefox funciona (véase la etiqueta @option)

Answer 3

creo que el post original tendría funcionaba sentían el código hecho dos cosas adicionales:

establecer los datos a JSON.serialize (persona) y establezca el tipo de datos a 'json' ya que el contentType era correcta, esto debería funcionar con la @PUT esperando a consumir JSON ...

Answer 4

Pruebe primero convertir los datos al formato JSON como @ wnm3 sugerido.

SI TODAVÍA problema del revestimiento Continuar -

Esto me ayudó, si su sintaxis de solicitud es correcta. Esto es lo que hice que eliminan el error 415 no compatible -

@PUT 
//REMOVE THIS LINE !!!!!! ----- @Produces(MediaType.APPLICATION_JSON) 
@Consumes(MediaType.APPLICATION_JSON) 
public Response addPerson(MyJSONObj myObj) 

    // 
    //Your code here 
    return Response.ok() 
      .header("Access-Control-Allow-Origin", "*") 
      .header("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS, HEAD") 
      .header("Access-Control-Allow-Headers", "Content-Type,Accept,X-Requested-With,authorization") 
      .header("Access-Control-Allow-Credentials", true) 
      .build(); 
} 

Yo no sé exactamente, cómo hacer la solicitud CORS que enviará y aceptar application/json. La respuesta dada por @Tobias Sarnow es parcialmente incorrecta. Como no necesita un método que acepte la solicitud de OPCIONES. Incluso si el navegador muestra que envía la solicitud de OPCIONES, aún buscará el método con la anotación @POST. Entonces, en lugar de poner un filtro o hacer otra cosa (formas más refinadas) lo hice mediante una solución rápida usando otro método sin @Consumes y @Produces. Ejemplo-

@PUT 
public Response addPerson() { 
    return Response.ok() 
      .header("Access-Control-Allow-Origin", "*") 
      .header("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS, HEAD") 
      .header("Access-Control-Allow-Headers", "Content-Type,Accept,X-Requested-With,authorization") 
      .header("Access-Control-Allow-Credentials", true) 
      .build(); 
} 

@PUT 
@Consumes(MediaType.APPLICATION_JSON) 
public Response addPerson(MyJSONObj myObj) 
    // 
    //Your code here 
    // 
    return Response.ok() 
      .header("Access-Control-Allow-Origin", "*") 
      .header("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS, HEAD") 
      .header("Access-Control-Allow-Headers", "Content-Type,Accept,X-Requested-With,authorization") 
      .header("Access-Control-Allow-Credentials", true) 
      .build(); 
} 

Entonces, ¿qué está pasando aquí es como CORS iniciales de las opciones está a cargo de primer método, entonces el segundo método controla la solicitud PUT originales.

Estoy poniendo esta respuesta aquí, ya que tardé 3-4 días en descubrir por qué mi solicitud de PUT no estaba siendo procesada. Por lo tanto, puede ayudar a alguien que está teniendo un error 415.