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

Nach meinem Verständnis:

1. Verwenden Sie @PathParam - wenn es sich um ein obligatorisches Element wie eine Id handelt

   GET /balloon/{id}

2. Verwenden Sie @QueryParam - wenn Sie die genaue Ressource haben, diese aber nach einigen optionalen Merkmalen wie Farbe, Größe usw. filtern müssen.

   GET /balloon/123?color=red&size=large

Answer 2

Ich gebe ein Beispiel, um zu verstehen, wann wir die @Queryparam y @pathparam

Ich nehme zum Beispiel eine Ressource ist carResource Klasse

Wenn Sie die Eingaben Ihrer Ressourcen-Methode obligatorisch machen wollen, verwenden Sie den Typ param als @pathaparam Wenn die Eingaben Ihrer Ressourcenmethode optional sein sollen, dann behalten Sie den Parametertyp als @QueryParam param

@Path("/car")
class CarResource
{
    @Get
    @produces("text/plain")
    @Path("/search/{carmodel}")
    public String getCarSearch(@PathParam("carmodel")String model,@QueryParam("carcolor")String color) {
        //logic for getting cars based on carmodel and color
            -----
        return cars
    }
}

Für diese Ressource übergeben Sie die Anfrage

req uri ://address:2020/carWeb/car/search/swift?carcolor=red

Wenn Sie eine Anfrage wie diese eingeben, wird die Ressource das zugrundeliegende Automodell und die Farbe liefern

 req uri://address:2020/carWeb/car/search/swift

Wenn Sie eine Anfrage wie diese eingeben, wird die Suchmethode nur das Auto mit dem schnellen Modell anzeigen

req://address:2020/carWeb/car/search?carcolor=red

Wenn Sie wie dies geben, erhalten wir ResourceNotFound Ausnahme, weil in der Auto-Resource-Klasse deklariert ich carmodel als @pathPram das heißt, Sie müssen und sollten das Fahrzeugmodell als reQ uri geben, sonst wird es nicht die Anforderung an Ressource übergeben, aber wenn Sie nicht die Farbe übergeben auch es wird die Anforderung an Ressource übergeben, warum, weil die Farbe ist @quetyParam es ist fakultativ in req.

Answer 3

Der Grund dafür ist eigentlich ganz einfach. Wenn Sie einen Abfrageparameter verwenden, können Sie Zeichen wie "/" verwenden, und Ihr Client muss sie nicht mit HTML kodieren. Es gibt noch andere Gründe, aber das ist ein einfaches Beispiel. Wann sollte man eine Pfadvariable verwenden? Ich würde sagen, immer dann, wenn Sie mit IDs arbeiten oder wenn die Pfadvariable eine Richtung für eine Abfrage ist.