Wann wird @QueryParam gegenüber @PathParam verwendet?

Question

Ich stelle nicht die Frage, die hier bereits gestellt wurde: Was ist der Unterschied zwischen @PathParam und @QueryParam

Dies ist eine Frage der "besten Praktiken" oder der Konventionen.

Wann würden Sie die @PathParam gegen @QueryParam .

Ich kann mir vorstellen, dass die Entscheidung die beiden verwendet, um das Informationsmuster zu unterscheiden. Lassen Sie mich unten meine LTPO - weniger als perfekte Beobachtung - illustrieren.

Die Verwendung von PathParam könnte für Informationskategorien reserviert werden, die gut in einen Zweig eines Informationsbaums passen würden. PathParam könnte verwendet werden, um die Hierarchie der Entitätsklassen aufzuschlüsseln.

QueryParam hingegen könnte für die Angabe von Attributen reserviert werden, um die Instanz einer Klasse zu finden.

Zum Beispiel,

• /Vehicle/Car?registration=123
• /House/Colonial?region=newengland

/category?instance

@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

gegen /category/instance

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

gegen ?category+instance

@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

Ich glaube nicht, dass es eine Standardkonvention dafür gibt. Gibt es eine? Ich würde jedoch gerne hören, wie die Leute PathParam vs. QueryParam verwenden, um ihre Informationen zu unterscheiden, wie ich es oben beschrieben habe. Ich würde auch gerne den Grund für diese Praxis erfahren.

Answer 1

Ich bevorzuge Folgendes:

@PfadParam

Wenn es sich um erforderliche Parameter wie ID, productNo

GET /user/details/{ID}
GET /products/{company}/{productNo}

@QueryParam

Wenn Sie optionale Parameter wie Filter, Online-Status und Sie können null

GET /user/list?country=USA&status=online
GET /products/list?sort=ASC 

Wenn beide verwendet werden

GET /products/{company}/list?sort=ASC

Answer 2

Sie können sowohl Abfrageparameter als auch Pfadparameter unterstützen, z. B. im Falle der Aggregation von Ressourcen, wenn die Sammlung von Unterressourcen für sich genommen sinnvoll ist.

/departments/{id}/employees
/employees?dept=id

Abfrageparameter können hierarchische und nicht-hierarchische Subsets unterstützen; Pfadparameter sind nur hierarchisch.

Ressourcen können mehrere Hierarchien aufweisen. Unterstützen Sie kurze Pfade, wenn Sie breite Untersammlungen abfragen wollen, die hierarchische Grenzen überschreiten.

/inventory?make=toyota&model=corolla
/inventory?year=2014

Verwenden Sie Abfrageparameter, um orthogonale Hierarchien zu kombinieren.

/inventory/makes/toyota/models/corolla?year=2014
/inventory/years/2014?make=toyota&model=corolla
/inventory?make=toyota&model=corolla&year=2014

Verwenden Sie nur Pfadparameter im Falle der Komposition - wenn eine Ressource getrennt von ihrer Mutter keinen Sinn ergibt und die globale Sammlung aller Kinder keine nützliche Ressource für sich ist.

/words/{id}/definitions
/definitions?word=id   // not useful

Answer 3

Kurz und bündig,

@Pathparam funktioniert für die Wertübergabe durch Ressourcen und Query String

• /user/1
• /user?id=1

@Queryparam funktioniert nur bei Wertübergabe Query String

• /user?id=1

Answer 4

1. @QueryParam kann bequem mit der Standardwert-Annotation verwendet werden, so dass Sie eine Null-Zeiger-Ausnahme vermeiden können, wenn kein Abfrageparameter übergeben wird.

Wenn Sie Abfrageparameter aus einer GET-Anfrage analysieren möchten, können Sie einfach entsprechende Parameter für die Methode definieren, die die GET-Anfrage bearbeitet, und sie mit @QueryParam Anmerkung

2. @PathParam extrahiert die URI-Werte und stimmt mit @Path . Und erhält somit die Eingabeparameter. 2.1 @PathParam kann mehr als eins sein und wird auf Methodenargumente gesetzt

   @Path("/rest")
   public class Abc {
   
       @GET
       @Path("/msg/{p0}/{p1}")
       @Produces("text/plain")
       public String add(@PathParam("p0") Integer param1, @PathParam("p1")  Integer param2 )
       {
           return String.valueOf(param1+param2);
       }
   } 

Im obigen Beispiel,
http://localhost:8080/Restr/rest/msg/{p0}/{p1} ,
p0 passt zu param1 y p1 passt zu param2 . Für den URI gilt also
http://localhost:8080/Restr/rest/msg/4/6 ,
erhalten wir das Ergebnis 10 .

Im REST-Dienst bietet JAX-RS @QueryParam y @FormParam beide für die Annahme von Daten aus HTTP-Anfragen. Ein HTTP-Formular kann mit verschiedenen Methoden wie GET und POST übermittelt werden.

@QueryParam : Nimmt GET-Anfragen entgegen und liest Daten aus dem Query-String.

@FormParam : Nimmt POST-Anfragen an und holt Daten aus einem HTML-Formular oder einer Medienanfrage

Answer 5

Für Ressourcennamen und IDs verwende ich @PathParams . Für optionale Variablen verwende ich @QueryParams