jquery Ajax Rest Anruf - nicht unterstützte Medientyp

Question

Ich habe eine einfache Jquery Ajax Anruf zu einem Rest Service. Ich setze den contentType als "application/json" und die Rest-Ressource ist konfiguriert, um "MediaType.APPLICATION_JSON" zu akzeptieren. Dies ist eine POST-Methode. Mit dieser Einrichtung erhalte ich "nicht unterstützten Medientyp" Fehler.

Die Header-Informationen zeigen "Content-Type application/json; charset = UTF-8" im Request-Header

Antwort zeigt: Bericht Status: Nicht unterstützten Medientyp Der Server diesen Antrag abgelehnt weil die Anforderungseinheit in einem Format vorliegt, das von der angeforderten Ressource für die angeforderte Methode nicht unterstützt wird (nicht unterstützter Medientyp).

Bitte geben Sie einige Hinweise, um dieses Problem zu beheben. Hier

ist der Code-Schnipsel:

Erholung Ressourcen

@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); 
     } 
    }); 
    }); 
}); 

Headers wie in FF Firebug angezeigt

Headers

Antwort

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

Anfrageheaders

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

Es sieht aus wie Sie eine undichte Abstraktion leiden kann. Sehen Sie diese Antwort: JQuery's getJSON() not setting Accept header correctly?

Wenn Sie einen Cross-Domain-Anruf tun, dann scheint es, Sie nicht in der Lage sind die Header akzeptieren zu setzen darauf zurückzuführen, wie jQuery den Anruf von Ihnen abstrahiert.

Sie sagen, dass der Server den richtigen Header akzeptiert, obwohl. Das könnte auf ein anderes Problem hinweisen.

Answer 2

Ich hatte das gleiche Problem und ich konnte es auf diese Weise lösen (siehe 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); 
    } 
}); 

Auf Java Seite ich diese (siehe Access-Control-Allow-Origin) hinzugefügt:

@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"); 

    // ... 
    // ... 
} 

Fazit

• JSON Objekt wird übertragen und automagically transformiert (weitere Details siehe Configuring JSON for RESTful Web Services)
• POST begehen
• Cross Domain (Same-Origin-Policy)
• Firefox funktioniert (siehe @ option tag)

Answer 3

ich denke, die Original-Beitrag würde der Code getan zwei weitere Dinge gearbeitet hatte:

setzen die Daten zu JSON.serialize (Person) und stellen Sie die datatype zu 'json' da die content korrekt war, sollte diese Arbeit mit der @PUT json verbrauchen erwarten ...

Answer 4

TRY THIS FIRST Ihre Daten zu JSON-Format konvertieren, wie @ wnm3 vorgeschlagen.

IF STILL PROBLEM FACING WEITER -

Das half mir, wenn Ihr Antrag Syntax korrekt ist. Das ist das, was ich tat, der die 415 Nicht unterstützte Fehler entfernen -

@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(); 
} 

ich genau weiß nicht, wie CORS Antrag zu stellen, die application/json sendet und akzeptieren. Die Antwort von @Tobias Sarnow ist teilweise falsch. Da Sie keine Methode benötigen, die OPTIONS-Anfrage akzeptiert. Auch wenn der Browser anzeigt, dass er die OPTIONS-Anfrage sendet, sucht er immer noch nach einer Methode mit @ POST Annotation. Anstatt also einen Filter aufzusetzen oder etwas anderes zu tun (raffiniertere Methoden), habe ich eine schnelle Methode verwendet, indem ich eine andere Methode ohne @Consumes und @Produces verwendet habe. Beispiel-

@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(); 
} 

Also, was hier passiert ist, als Ausgang CORS für OPTIONS durch erstes Verfahren behandelt wird dann die zweite Methode behandelt die ursprüngliche PUT-Anfrage.

Ich setze diese Antwort hier, da ich 3-4 Tage brauchte, um herauszufinden, warum meine PUT-Anfrage nicht durchging. So kann es jemandem helfen, der 415 Fehler hat.