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

Sie können Abfrageparameter für die Filterung und Pfadparameter für die Gruppierung verwenden. Der folgende Link enthält gute Informationen dazu Wann sollten pathParams oder QueryParams verwendet werden?

Answer 2

Das ist eine sehr interessante Frage.

Sie können beide verwenden, es gibt keine strikte Regel zu diesem Thema, aber die Verwendung von URI-Pfadvariablen hat einige Vorteile:

• Cache : Die meisten Web-Cache-Dienste im Internet zwischenspeichern keine GET-Anfragen, wenn sie Abfrageparameter enthalten. Sie tun dies, weil es viele RPC-Systeme gibt, die GET-Anfragen verwenden, um Daten auf dem Server zu ändern (Fail!! Get muss eine sichere Methode sein).

Wenn Sie jedoch Pfadvariablen verwenden, können alle diese Dienste Ihre GET-Anfragen zwischenspeichern.

• Hierarchie : Die Pfadvariablen können eine Hierarchie darstellen: /Stadt/Straße/Ort

Sie gibt dem Benutzer mehr Informationen über die Struktur der Daten.

Wenn Ihre Daten jedoch keine Hierarchiebeziehung aufweisen, können Sie trotzdem Pfadvariablen verwenden, indem Sie Komma oder Semikolon verwenden:

/Stadt/Längengrad,Breitengrad

Verwenden Sie in der Regel ein Komma, wenn die Reihenfolge der Parameter wichtig ist, und ein Semikolon, wenn die Reihenfolge keine Rolle spielt:

/IconGenerator/rot;blau;grün

Abgesehen von diesen Gründen gibt es einige Fälle, in denen es sehr üblich ist, Query-String-Variablen zu verwenden:

• Wenn Sie möchten, dass der Browser automatisch HTML-Formularvariablen in den URI einfügt
• Wenn Sie es mit einem Algorithmus zu tun haben. Zum Beispiel die Google-Maschine verwenden Abfragezeichenfolgen:

http:// www.google.com/search?q=rest

Zusammenfassend lässt sich sagen, dass es keinen zwingenden Grund gibt, eine dieser Methoden zu verwenden, aber wann immer Sie können, sollten Sie URI-Variablen verwenden.

Answer 3

Aus Wikipedia: Uniform Resource Locator

Ein Weg die Daten enthält, in der Regel in hierarchischer Form organisiert der als eine Folge von durch Schrägstriche getrennten Segmenten erscheint.

Eine optionale Abfrage die durch ein Fragezeichen (?) vom vorangehenden Teil getrennt ist und eine Abfragezeichenfolge von nicht-hierarchische Daten .

- Je nach Konzept der URL können wir einen PathParam für hierarchische Daten/Richtlinien/Locator-Komponenten oder einen QueryParam implementieren, wenn die Daten nicht hierarchisch sind. Dies ist sinnvoll, da Pfade von Natur aus geordnet sind, während Abfragen Variablen enthalten, die beliebig geordnet sein können (ungeordnete Variablen/Wertpaare).

Ein früherer Kommentator schrieb,

Ich denke, wenn der Parameter eine bestimmte Entität identifiziert, sollten Sie eine Pfadvariable verwenden.

Ein anderer schrieb,

Verwenden Sie @PathParam für den Abruf auf der Grundlage von id. Verwenden Sie @QueryParam für Filter oder wenn Sie eine feste Liste von Optionen haben, die der Benutzer übergeben kann.

Eine andere,

Ich würde empfehlen, alle erforderlichen Parameter in den Pfad zu setzen, und alle optionalen Parameter sollten auf jeden Fall Query-String-Parameter sein.

- Man könnte jedoch ein flexibles, nicht-hierarchisches System zur Identifizierung bestimmter Entitäten einführen! Man könnte mehrere eindeutige Indizes auf einer SQL-Tabelle haben und es ermöglichen, Entitäten anhand einer beliebigen Kombination von Feldern zu identifizieren, die einen eindeutigen Index bilden! Unterschiedliche Kombinationen (vielleicht auch unterschiedlich geordnet) könnten für Links von verschiedenen verwandten Entitäten (Referrern) verwendet werden. In diesem Fall könnten wir es mit nicht-hierarchischen Daten zu tun haben, die zur Identifizierung einzelner Entitäten verwendet werden - oder in anderen Fällen könnten wir nur bestimmte Variablen/Felder - bestimmte Komponenten eindeutiger Indizes - angeben und eine Liste/Satz von Datensätzen abrufen. In solchen Fällen könnte es einfacher, logischer und sinnvoller sein, die URLs als QueryParams zu implementieren!

Könnte eine lange hexadezimale Zeichenfolge den Wert von Schlüsselwörtern im Rest des Pfads verwässern/verringern? Es könnte sich lohnen Berücksichtigung der potenziellen SEO-Implikationen der Platzierung von Variablen/Werten im Pfad oder in der Abfrage und die Auswirkungen auf die menschliche Schnittstelle, ob wir wollen, dass die Benutzer die Hierarchie der URLs durch die Bearbeitung des Inhalts der Adressleiste durchlaufen/erforschen können. Meine Seite "404 Not Found" verwendet SSI-Variablen, um fehlerhafte URLs automatisch auf ihre übergeordnete Seite umzuleiten! Auch Suchroboter könnten die Pfadhierarchie durchlaufen. Andererseits entferne ich persönlich bei der Weitergabe von URLs in sozialen Medien manuell alle privaten eindeutigen Bezeichner - in der Regel durch Kürzen der Abfrage aus der URL, so dass nur der Pfad übrig bleibt: In diesem Fall ist es von gewissem Nutzen, eindeutige Bezeichner im Pfad statt in der Abfrage unterzubringen. Ob wir die Verwendung von Pfadkomponenten als grobe Benutzerschnittstelle erleichtern wollen, hängt vielleicht davon ab, ob die Daten/Komponenten für Menschen lesbar sind oder nicht. Die Frage der Lesbarkeit hängt in gewisser Weise mit der Frage der Hierarchie zusammen: Oft sind Daten, die als lesbare Schlüsselwörter ausgedrückt werden können, auch hierarchisch, während hierarchische Daten oft als lesbare Schlüsselwörter ausgedrückt werden können. (Suchmaschinen selbst könnten als Erweiterung der Verwendung von URLs als Benutzerschnittstelle definiert werden). Hierarchien von Schlüsselwörtern oder Richtlinien sind vielleicht nicht streng geordnet, aber sie liegen in der Regel nahe genug beieinander, dass wir alternative Fälle im Pfad abdecken können, und eine Option als den "kanonischen" Fall bezeichnen .

Es gibt grundsätzlich mehrere Arten von Fragen, die wir mit der URL für jede Anfrage beantworten können:

1. Um welche Art von Aufzeichnung/ Sache bitten wir/ dienen wir?
2. Welche(r) ist/sind für uns von Interesse?
3. Wie wollen wir die Informationen/Aufzeichnungen präsentieren?

Q1 wird mit ziemlicher Sicherheit am besten durch den Pfad oder durch PathParams abgedeckt. Q3 (das wahrscheinlich über eine Reihe von beliebig angeordneten optionalen Parametern und Standardwerten gesteuert wird); wird mit ziemlicher Sicherheit am besten durch QueryParams abgedeckt. Q2: Es kommt darauf an

Answer 4

PFADPARAMETER - Der Pfadparameter ist eine Variable im URL-Pfad, die hilft, auf eine bestimmte Ressource zu verweisen.

Example - https://sitename.com/questions/115

Wenn 115 ein Pfadparameter ist, kann er durch eine andere gültige Zahl geändert werden, um eine andere Ressource in derselben Anwendung abzurufen/auf sie zu verweisen.

ABFRAGEPARAMETER - Abfrageparameter sind Variablen im URL-Pfad, die bestimmte Ressourcen aus der Liste herausfiltern.

Example - https://sitename.com/questions/115?qp1=val1&qp2=val2&qp3=val3

Hier sind qp1, qp2 und qp3 Abfragevariablen mit den Werten val1, val2 und val3. Diese können beim Abrufen/Speichern unserer Daten als Filter verwendet werden. Abfragevariablen werden in der URL immer nach einem Fragezeichen(?) angehängt.

Answer 5

Wie theon bemerkte, ist REST kein Standard. Wenn Sie jedoch eine auf Standards basierende URI-Konvention implementieren möchten, könnten Sie die oData-URI-Konvention . Ver 4 wurde als OASIS-Standard genehmigt und Bibliotheken gibt es für oData für verschiedene Sprachen, darunter Java über Apache Olingo . Lassen Sie sich nicht von der Tatsache abschrecken, dass es sich um eine Ausgeburt von Microsoft handelt, denn es ist auch von anderen Akteuren der Branche unterstützt wird zu denen Red Hat, Citrix, IBM, Blackberry, Drupal, Netflix, Facebook und SAP gehören.

Weitere Paten sind hier aufgelistet