2015-03-12 5 views
5

Ich habe eine JAX-RS-basierte ReST-Anwendung mit Apache Wink geschrieben und ich verstand das Konzept der Zuordnung zwischen Pfadparameter zu Ressource behandeln Klasse. Hier sehe ich, dass wir Pfade mit @Path Annotation und entsprechende Ressource definieren können, die basierend auf HTTP-Methode aufgerufen wird.Wie schreibe ich einzelne JAX-RS-Ressource für variable Anzahl von Pfadparametern

Nun schaue ich auf etwas wie eine Ressource, die für variable Anzahl der Pfadparameter aufgerufen werden sollte.

Zum Beispiel Ich möchte meine einzige Ressourcenklasse CollegeResource sollte für URIs wie /rest/college, /rest/college/subject, /rest/college/subject/teachers, aufgerufen werden und es kann bis zu einer beliebigen Anzahl von Pfad-Parameter gehen.

Wenn ich die Anzahl von Pfadparametern in vorher kenne, dann hätte ich das mit etwas wie diesem /rest/college/{param1}/{param2} erreichen können. Die Anzahl der Pfadparameter ist jedoch unbekannt. So fühlte ich (ich kann falsch liegen) kann diesen Ansatz nicht verwenden.

Eine weitere Möglichkeit, die ich noch verwenden könnte, ist die Verwendung von Abfrageparametern. Aber ich möchte, dass dies nur als Pfadparameter zur Verfügung steht.

Gibt es eine Möglichkeit, dies mit Apache Wink mit einer anderen Konfiguration zu tun? Wenn nicht in Apache Wink, unterstützen andere JAX-RS-Implementierungen dies?

Antwort

7

Sie können eine Regex wie @Path("/college/{param: .*}") verwenden und dann List<PathSegment> als Methodenparameter verwenden. Zum Beispiel

@GET 
@Path("/college/{params: .*}") 
public Response get(@PathParam("params") List<PathSegment> params) { 
    StringBuilder builder = new StringBuilder(); 
    for (PathSegment seg: params) { 
     builder.append(seg.getPath()); 
    } 
    return Response.ok(builder.toString()).build(); 
} 

C:\>curl -v http://localhost:8080/college/blah/hello/world/cool
Ergebnis:blahhelloworldcool

Aber persönlich, würde ich bleiben von dieser Art der Sache entfernt. Ihre URI-Pfade (Templates) sollten eine semantische Bedeutung haben. Das Zulassen einer beliebigen Anzahl von Pfadparametern, die möglicherweise keine Bedeutung haben, ist fehleranfällig und IMO ist ein Grund für ein Redesign. Ich müsste die Semantik hinter dieser Designauswahl kennen, bevor ich jedoch einen Ratschlag geben kann.

+0

Ich schaue, wenn ich RDBMS aufrufen, werde ich 3 Objekte (Datenbankname, Schemaname und Tabellenname) in den Pfad Params senden. Meine URL wird wie **/api/database/dbname/schemaname/tablename ** sein. Aber während ich Salesforce.com anrufe, sende ich nur ein SFDC-Objekt und meine URL wird **/api/sfdc/Account ** sein. Hier möchte ich nicht mehrere Ressourcen für jede Zielanwendung haben. Ich möchte also eine einzelne Ressource mit Basis-URI/api/{targetAppName} haben, und dies kann eine beliebige Anzahl von Pfadparametern haben. Ich kann im Code auf {targetAppName} zugreifen und die Zielanwendung festlegen und die entsprechenden Aufgaben ausführen. –

+0

Und Sie möchten nur eine Ressourcenmethode, um alle möglichen Anwendungsfälle zu behandeln? Wenn das ist, was Sie wollen, dann gehen Sie dafür –

+0

Works. Schlussfolgerung für diesen Thread wäre, mit {params:. *}, Können wir es generisch machen. –

Verwandte Themen