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

REST ist zwar kein Standard im eigentlichen Sinne, aber die Lektüre der allgemeinen REST-Dokumentation und von Blogbeiträgen sollte Ihnen einige Richtlinien für eine gute Strukturierung von API-URLs geben. Die meisten Rest-APIs neigen dazu, nur Ressourcennamen und Ressourcen-IDs im Pfad zu haben. Zum Beispiel:

/departments/{dept}/employees/{id}

Einige REST-APIs verwenden Query-Strings zum Filtern, Paginieren und Sortieren, aber da REST kein strikter Standard ist, empfehle ich, einige REST-APIs zu prüfen, wie z. B. github y Stackoverflow und sehen Sie, was für Ihren Anwendungsfall gut funktionieren könnte.

Ich würde empfehlen, alle erforderlichen Parameter in den Pfad zu setzen, und alle optionalen Parameter sollten auf jeden Fall Query-String-Parameter sein. Wenn man optionale Parameter in den Pfad einfügt, wird es sehr unübersichtlich, wenn man versucht, URL-Handler zu schreiben, die verschiedenen Kombinationen entsprechen.

Answer 2

Das ist meine Aufgabe.

Wenn es ein Szenario gibt, um einen Datensatz auf der Grundlage der ID abzurufen, z. B. müssen Sie die Details des Mitarbeiters, dessen ID 15 ist, dann können Sie Ressource mit @PathParam haben.

GET /employee/{id}

Wenn es ein Szenario gibt, in dem Sie die Details aller Mitarbeiter benötigen, aber nur 10 auf einmal, können Sie den Abfrageparameter

GET /employee?start=1&size=10

Dies bedeutet, dass ab der Mitarbeiter-ID 1 zehn Datensätze angezeigt werden.

Zusammenfassend lässt sich sagen, dass @PathParam für den Abruf auf der Grundlage von id verwendet wird. Verwenden Sie @QueryParam für Filter oder wenn Sie eine feste Liste von Optionen haben, die der Benutzer übergeben kann.

Answer 3

Ich denke, wenn der Parameter eine bestimmte Einheit identifiziert, sollten Sie eine Pfadvariable verwenden. Um zum Beispiel alle Beiträge in meinem Blog abzurufen, fordere ich

GET: myserver.com/myblog/posts

um den Beitrag mit id = 123 zu erhalten, würde ich Folgendes anfordern

GET: myserver.com/myblog/posts/123

aber um meine Liste der Beiträge zu filtern und alle Beiträge seit dem 1. Januar 2013 zu erhalten, würde ich Folgendes anfordern

GET: myserver.com/myblog/posts?since=2013-01-01

Im ersten Beispiel identifiziert "posts" eine bestimmte Entität (die gesamte Sammlung von Blogbeiträgen). Im zweiten Beispiel steht "123" ebenfalls für eine bestimmte Entität (einen einzelnen Blogeintrag). Im letzten Beispiel hingegen ist der Parameter "since=2013-01-01" eine Aufforderung zum Filtern der Beitragssammlung und keine bestimmte Entität. Ein weiteres gutes Beispiel wäre die Paginierung und Anordnung, d. h.

GET: myserver.com/myblog/posts?page=2&order=backward

Ich hoffe, das hilft. :-)

Answer 4

Bevor wir über QueryParam & PathParam sprechen. Lassen Sie uns zunächst die URL und ihre Komponenten verstehen. Die URL besteht aus Endpunkt + Ressource + QueryParam/ PathParam.

Zum Beispiel,

URL: https://app.orderservice.com/order?order=12345678

o

URL: https://app.orderservice.com/orders/12345678

wobei

Endpunkt: https://app.orderservice.com

Ressource: Aufträge

queryParam: order=12345678

PfadParam: 12345678

@QueryParam:

QueryParam wird verwendet, wenn die Anforderung besteht, die Anfrage nach bestimmten Kriterien zu filtern. Die Kriterien werden mit ? nach der Ressource in der URL angegeben. Mehrere Filterkriterien können im QueryParam durch das Symbol & angegeben werden.

Zum Beispiel:

https://app.orderservice.com/orders?order=12345678 & customername=X

@PathParam:

PathParam wird verwendet, wenn die Anforderung besteht, eine bestimmte Reihenfolge auf der Grundlage von guid/id auszuwählen. PathParam ist der Teil der Ressource in der URL.

Zum Beispiel:

https://app.orderservice.com/orders/12345678

Answer 5

Ich persönlich habe den Ansatz "wenn es für den Benutzer sinnvoll ist, ein Lesezeichen für eine URL zu setzen, die diese Parameter enthält, dann verwenden Sie PathParam".

Wenn beispielsweise die URL für ein Benutzerprofil einen Profil-ID-Parameter enthält, der vom Benutzer mit einem Lesezeichen versehen und/oder per E-Mail verschickt werden kann, würde ich diese Profil-ID als Pfadparameter hinzufügen. Ein weiterer Aspekt ist, dass sich die Seite, auf die die URL verweist, die den Pfad-Parameter enthält, nicht ändert - der Benutzer wird sein Profil einrichten, es speichern und dann wahrscheinlich nicht mehr viel ändern; das bedeutet, dass Webcrawler/Suchmaschinen/Browser/etc diese Seite auf der Grundlage des Pfades gut zwischenspeichern können.

Wenn ein in der URL übergebener Parameter das Layout/den Inhalt der Seite verändern kann, würde ich ihn als Queryparam verwenden. Wenn zum Beispiel die Profil-URL einen Parameter unterstützt, der angibt, ob die E-Mail des Benutzers angezeigt werden soll oder nicht, würde ich dies als Abfrageparameter betrachten. (Ich weiß, man könnte wohl sagen, dass die &noemail=1 oder was auch immer für ein Parameter es ist, kann als Pfad-Parameter verwendet werden und erzeugt 2 getrennte Seiten - eine mit der E-Mail, eine ohne - aber logischerweise ist das nicht der Fall: es ist immer noch die gleiche Seite mit oder ohne bestimmte Attribute angezeigt.

Ich hoffe, das hilft - ich bin mir bewusst, dass die Erklärung ein wenig unscharf sein könnte :)