HTTP content-negotiation Konflikte in JAX-RS/Jersey?

Genieße ich die automatische HTTP-content-negotiation für JAX-RS (speziell Jersey), D. H. seine Fähigkeit zur route "meine Ressourcen" durch "Annehmen" und/oder "Content-Type" - Header. Aber ich finde, dass es manchmal nicht gib mir genug Steuern, wenn es einen Konflikt gibt.

Betrachten Sie beispielsweise die folgenden Endpunkte:

@Path("/order")
public class OrderController {

    @GET
    @Path("{orderID: \\d+}")
    @Produces("text/html")
    public View getOrderView(@PathParam("orderID") long id) {
        Order order = this.getOrderData(id);
        return new OrderView(order);
    }

    @GET
    @Path("{orderID: \\d+}")
    @Produces({"application/json", "application/xml"})
    public Order getOrderData(@PathParam("orderID") long id) {
        return new OrderService.findOrder(id);
    }
}

Bekomme ich unterschiedliche Ergebnisse zwischen Firefox und Chrome. Firefox wird eine Karte, um die HTML-Endpunkt, während Chrome löst die XML-Endpunkt, wenn ich navigieren die einzelnen, um die Endpunkt-URL. Der Unterschied zwischen Ihnen ist die Reihenfolge der aufgeführten MIME-Typen in Ihre Accept-Header. Chrome sendet die folgenden:

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.107 Safari/534.13
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Versus in Firefox listet HTML erste:

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Scheint logisch, dass es mit dem ersten Eintrag, wenn alle werden gleich gewichtet. Aber in meinem Fall bin ich immer die unterschiedlichen Ergebnisse, als ich möchte, so wäre es schön, um zu bestimmen, eine bessere Methode für tie-breaking.

Meine Frage: kurz, die Injektion header-Informationen in diese Methoden und die Durchführung der media-Typ der Verarbeitung selbst, gibt es eine Möglichkeit zu "optimieren der GEWICHTE", so zu sprechen, im Falle eines Unentschiedens? Zum Beispiel, kann ich sagen, es immer Trumpf XML mit HTML? Meine Rest-clients sind sehr explizit, welche Art Sie wollen zurück, aber Browser sind notorisch schlampig mit Accept-Header. (Ich persönlich denke, Sie sollten Gewicht zu HTML leicht über XML-da dies ist, was die Nutzer erwarten aber es ist ein wenig spät.)

Alternativ kann ich mein eigenen content negotiation nur einmal in einem zentralen Ort? Ich bin nicht gegen das schreiben dieser Logik heraus manuell, aber nicht wenn es bedeutet, dass die Anwendung auf jeden einzelnen Fall an meine Ressourcen. Tut JAX-RS haben einige das Konzept der das hinzufügen eines filters, um die pipeline zu optimieren, Anfragen, bevor Sie weitergeleitet werden?

InformationsquelleAutor mckamey | 2011-03-09
  1. 1

    Als das Trikot Bedienungsanleitung Staaten:

    Wenn beide gleichermaßen akzeptabel, dann der erstere wird gewählt, weil es zuerst erscheint.

    Aus, was ich weiß, dies lässt Sie mit zwei Möglichkeiten/hacks:

    1. Anhängen der Datei-Erweiterung
      URIs zu überschreiben, den Accept-header

    2. Schreiben Sie ein servlet-filter, der
      überschreibt den Accept-header für
      Benutzerprogramme

    • Dank der Servlet-filter scheint gut zu funktionieren. Interessanterweise fand ich einen Kerl, der die Kombination Ihrer zwei Vorschläge; er schreibt einen servlet-filter in der Lage sein zu ersetzen, die Dateiendung mit einem Accept-header. Es gibt einen Tippfehler in seinem code aber als sein kopfball überprüfen Sie groß-und Kleinschreibung. Trotzdem interessant: zienit.nl/blog/2010/01/rest/...
    • Hier ist eine modifizierte Servlet-Filter, die Unterstützung für Datei-Erweiterungen und Updates der WebKit-Accept-header bestellen. gist.github.com/865216
    • diese Ergänzungen in die Kommentare, die Sie geschrieben werden sollte, verwandelte sich in eine Antwort, denn Kommentare werden nicht bedeutet, um zu überleben für immer
    InformationsquelleAutor Christoph Metzendorf
  2. 10

    Es ist ein Mechanismus, der im Trikot zum überschreiben der relative Grad der Präferenz aus den HTTP-Accept-header. Fügen Sie einfach einen parameter "qs" an die @Produziert Anmerkung, die Sie wollen, haben Vorrang. In deinem Fall:
    @Produces("text/html;qs=2")
    Beachten Sie, dass die http - "q" - Werte im Bereich von 0-1 und das Trikot "qs" - Werte sollte >= 1 (1 ist default).

    (Ich erfuhr dies von diese Quelle, und ich schrieb eine kleine Notiz für mich selbst hier)

    • Ich habe festgestellt, dass diese Lösung hat einige Probleme mit ihm. First off, es geht die ";qs=2" den ganzen Weg nach unten, um den client über den Content-Type-header. Aber der deal breaker war, dass es viel zu schwer das Gewicht. Zum Beispiel, jQuery-Anfragen mit "Accept: application/json, text/javascript, /; q=0.01", sondern mit "text/html;qs=2" und "application/json", Jersey sendet HTML über JSON.
    InformationsquelleAutor Erik
Schreibe einen Kommentar