wake-up-neo.com

Verwendung von @QueryParam vs @PathParam

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

Dies ist eine "Best Practices" - oder Konventionsfrage.

Wann würden Sie @PathParam vs @QueryParam verwenden?.

Was ich davon halten kann, könnte die Entscheidung darin bestehen, die beiden zur Unterscheidung des Informationsmusters zu verwenden. Lassen Sie mich unter meinem LTPO veranschaulichen - weniger als perfekte Beobachtung.

Die Verwendung von PathParam könnte für eine Informationskategorie reserviert sein, die gut in einen Zweig eines Informationsbaums passt. PathParam kann verwendet werden, um einen Drilldown zur Entitätsklassenhierarchie durchzuführen.

QueryParam kann für die Angabe von Attributen reserviert werden, um die Instanz einer Klasse zu lokalisieren.

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) ;

vs /category/instance

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

vs ?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? Ich würde jedoch gerne erfahren, wie Leute PathParam vs QueryParam verwenden, um ihre Informationen zu differenzieren, wie ich oben gezeigt habe. Ich würde auch gerne den Grund hinter der Praxis hören.

246
Blessed Geek

REST ist möglicherweise kein Standard, aber das Lesen der allgemeinen REST Dokumentation und Blog-Posts sollte Ihnen einige Richtlinien für eine gute Strukturierung von API-URLs geben. Die meisten Rest-APIs enthalten in der Regel nur Ressourcennamen und Ressourcen-IDs im Pfad. Sowie:

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

Einige REST-APIs verwenden Abfragezeichenfolgen zum Filtern, Paginieren und Sortieren, aber da REST kein strenger Standard ist, würde ich empfehlen, einige REST-APIs zu überprüfen wie github und stackoverflow und sehen, was für Ihren Anwendungsfall gut funktionieren könnte.

Ich würde empfehlen, alle erforderlichen Parameter in den Pfad einzufügen, und alle optionalen Parameter sollten auf jeden Fall Abfragezeichenfolgenparameter sein. Wenn Sie optionale Parameter in den Pfad eingeben, wird dies beim Schreiben von URL-Handlern, die verschiedenen Kombinationen entsprechen, sehr unübersichtlich.

228
theon

Das ist was ich mache.

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

GET /employee/{id}

Wenn es ein Szenario gibt, in dem Sie die Details aller Mitarbeiter abrufen müssen, jedoch jeweils nur 10, können Sie den Abfrageparameter verwenden

GET /employee?start=1&size=10

Dies besagt, dass ab Mitarbeiter-ID 1 zehn Datensätze abgerufen werden.

Um zusammenzufassen, verwenden Sie @PathParam zum Abrufen basierend auf der ID. Benutzer @QueryParam für Filter oder wenn Sie eine feste Liste von Optionen haben, die der Benutzer übergeben kann.

82

Ich denke, wenn der Parameter eine bestimmte Entität identifiziert, sollten Sie eine Pfadvariable verwenden. Um beispielsweise alle Posts in meinem Blog zu erhalten, fordere ich an

GET: myserver.com/myblog/posts

um den post mit id = 123 zu bekommen, würde ich bitten

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 darum bitten

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

Im ersten Beispiel kennzeichnet "posts" eine bestimmte Entität (die gesamte Sammlung von Blogposts). Im zweiten Beispiel steht "123" auch für eine bestimmte Entität (einen einzelnen Blogeintrag). Im letzten Beispiel ist der Parameter "since = 2013-01-01" eine Anforderung zum Filtern der Posts-Auflistung, die keine bestimmte Entität ist. Paginierung und Anordnung wären ein weiteres gutes Beispiel, d.h.

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

Ich hoffe, das hilft. :-)

41
10GritSandpaper

Ich persönlich habe den Ansatz "Wenn es für den Benutzer sinnvoll ist, eine URL mit einem Lesezeichen zu versehen, die diese Parameter enthält, verwenden Sie PathParam" verwendet.

Wenn die URL für ein Benutzerprofil beispielsweise einen Profil-ID-Parameter enthält, würde ich diese Profil-ID als Pfadparameter einfügen, da dies vom Benutzer mit einem Lesezeichen versehen und/oder per E-Mail versendet werden kann. Ein weiterer Aspekt ist, dass sich die Seite, die durch die URL angegeben wird, die den Pfadparameter enthält, nicht ändert. Der Benutzer richtet sein/ihr Profil ein, speichert es und wird dann wahrscheinlich nicht mehr so ​​viel ändern. Dies bedeutet, dass Webcrawler/Suchmaschinen/Browser/usw. diese Seite auf der Grundlage des Pfads schön zwischenspeichern können.

Wenn ein in der URL übergebener Parameter wahrscheinlich das Seitenlayout/den Inhalt ändert, würde ich das als Queryparam verwenden. Wenn beispielsweise die Profil-URL einen Parameter unterstützt, der angibt, ob die Benutzer-E-Mail angezeigt werden soll oder nicht, würde ich dies als Abfrageparameter betrachten. (Ich weiß, man könnte wohl sagen, dass der &noemail=1 oder welcher Parameter auch immer als Pfadparameter verwendet werden kann und 2 separate Seiten generiert - eine mit der E-Mail darauf, eine ohne - aber logischerweise ist das so nicht der Fall: Es ist immer noch dieselbe Seite mit oder ohne bestimmte Attribute.

Hoffe das hilft - ich schätze die Erklärung könnte etwas unscharf sein :)

8
Liv

Sie können Abfrageparameter zum Filtern und Pfadparameter zum Gruppieren verwenden. Der folgende Link enthält gute Informationen zu diesem Thema Verwendung von pathParams oder QueryParams

7
Chandra

Das ist eine sehr interessante Frage.

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

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

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

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

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

Wenn Ihre Daten jedoch keine Hierarchiebeziehung haben, können Sie weiterhin Pfadvariablen mit Komma oder Semikolon verwenden:

/ Stadt/Länge, Breite

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

/ IconGenerator/rot; blau; grün

Abgesehen von diesen Gründen kommt es in einigen Fällen häufig vor, dass Abfragezeichenfolgenvariablen verwendet werden:

  • Wenn der Browser HTML-Formularvariablen automatisch in den URI einfügen soll
  • Wenn es um Algorithmen geht. Beispielsweise verwendet die Google-Engine Abfragezeichenfolgen:

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

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

4
jfcorugedo

Aus Wikipedia: Uniform Resource Locator

Ein Pfad , der Daten enthält , die normalerweise in hierarchischer Form organisiert sind und als Folge von Segmenten angezeigt werden durch Schrägstriche getrennt.

Eine optionale Abfrage , die vom vorhergehenden Teil durch ein Fragezeichen (?) Getrennt ist und eine nicht hierarchische Abfragezeichenfolge enthält Daten.

- Je nach Konzeption der URL können wir ein PathParam für hierarchische Daten/Direktiven/Locator-Komponenten oder ein QueryParam implementieren, wenn die Daten nicht hierarchisch sind. Dies ist sinnvoll, da Pfade natürlich geordnet sind, während Abfragen Variablen enthalten, die beliebig geordnet sein können (ungeordnete Variablen/Wert-Paare).

Ein vorheriger Kommentator schrieb:

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

Ein anderer schrieb:

Verwenden Sie @PathParam zum Abrufen basierend auf der ID. Benutzer @QueryParam für Filter oder wenn Sie eine feste Liste von Optionen haben, die der Benutzer übergeben kann.

Ein weiterer,

Ich würde empfehlen, alle erforderlichen Parameter in den Pfad einzufügen, und alle optionalen Parameter sollten auf jeden Fall Abfragezeichenfolgenparameter sein.

- Man könnte jedoch ein flexibles, nicht hierarchisches System zur Identifizierung bestimmter Entitäten implementieren! Möglicherweise verfügt eine SQL-Tabelle über mehrere eindeutige Indizes und ermöglicht die Identifizierung von Entitäten mithilfe einer beliebigen Kombination von Feldern, die einen eindeutigen Index enthalten. Verschiedene Kombinationen (möglicherweise auch in anderer Reihenfolge) können für Links von verschiedenen verwandten Entitäten (Verweisen) verwendet werden. In diesem Fall handelt es sich möglicherweise um nicht hierarchische Daten, mit denen einzelne Entitäten identifiziert werden, oder in anderen Fällen werden möglicherweise nur bestimmte Variablen/Felder - bestimmte Komponenten eindeutiger Indizes - angegeben und eine Liste/ein Satz von Datensätzen abgerufen. In solchen Fällen ist es möglicherweise einfacher, logischer und sinnvoller, die URLs als QueryParams zu implementieren!

Könnte eine lange hexadezimale Zeichenfolge den Wert von Schlüsselwörtern im restlichen Pfad verdünnen/verringern? Es könnte sich lohnen nter Berücksichtigung der möglichen SEO-Auswirkungen des Platzierens von Variablen/Werten im Pfad oder in der Abfrage und der Auswirkungen auf die Benutzerschnittstelle, ob Benutzer die Hierarchie durchqueren/erkunden können sollen von URLs durch Bearbeiten des Inhalts der Adressleiste. Meine 404 Not Found-Seite verwendet SSI-Variablen, um defekte URLs automatisch an ihre Eltern weiterzuleiten! Suchroboter können auch die Pfadhierarchie durchlaufen. Auf der anderen Seite entferne ich beim Teilen von URLs in sozialen Medien manuell alle privaten eindeutigen Bezeichner - in der Regel, indem ich die Abfrage von der URL abschneide und nur den Pfad lasse im Pfad und nicht in der Abfrage. Ob wir die Verwendung von Pfadkomponenten als einfache Benutzeroberfläche vereinfachen möchten, hängt möglicherweise davon ab, ob die Daten/Komponenten für den Menschen lesbar sind oder nicht. Die Frage der Lesbarkeit hat etwas mit der Frage der Hierarchie zu tun: Oft sind Daten, die als lesbare Schlüsselwörter ausgedrückt werden können, auch hierarchisch. Während hierarchische Daten häufig als für Menschen lesbare Schlüsselwörter ausgedrückt werden. (Suchmaschinen selbst können so definiert werden, dass sie die Verwendung von URLs als Benutzeroberfläche erweitern.) Hierarchien von Schlüsselwörtern oder Direktiven sind möglicherweise nicht streng geordnet, sie sind jedoch normalerweise nah genug, um alternative Fälle im Pfad abzudecken. Eine Option als "kanonischen" Fall bezeichnen .

Grundsätzlich gibt es verschiedene Arten von Fragen, die wir mit der URL für jede Anfrage beantworten können:

  1. Welche Art von Aufzeichnung fordern wir an?
  2. Welche (n) interessieren uns?
  3. Wie wollen wir die Informationen/Aufzeichnungen präsentieren?

Q1 wird mit ziemlicher Sicherheit am besten vom Pfad oder von PathParams abgedeckt. Q3 (der wahrscheinlich über einen Satz willkürlich geordneter optionaler Parameter und Standardwerte gesteuert wird); wird mit ziemlicher Sicherheit am besten von QueryParams abgedeckt. F2: Es kommt darauf an ...

2
Matthew Slyman

Wie bereits erwähnt, ist REST kein Standard. Wenn Sie jedoch eine standardbasierte URI-Konvention implementieren möchten, sollten Sie die oData URI-Konvention berücksichtigen. Ver 4 wurde als OASIS-Standard genehmigt und es gibt Bibliotheken für oData für verschiedene Sprachen, einschließlich Java über Apache Olingo . Lassen Sie sich nicht von der Tatsache abschrecken, dass es sich um einen Spawn von Microsoft handelt, der Sie abschreckt, da er auch von anderen Branchenplayern unterstützt , zu denen Red Hat, Citrix, IBM, Blackberry, Drupal, Netflix Facebook und SAP gehören

Weitere Adopters sind hier aufgelistet

2
MikeM

Ich gebe ein Beispiel für Undersand, wann wir @Queryparam und @pathparam verwenden

Ich nehme zum Beispiel eine Ressource der Klasse carResource

Wenn Sie die Eingaben Ihrer Ressourcenmethode manuell vornehmen möchten, verwenden Sie den Parametertyp als @pathaparam. Wenn die Eingaben Ihrer Ressourcenmethode optional sein sollen, behalten Sie diesen Parametertyp als @QueryParam param bei

@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
    }
}

Bestätigen Sie die Anfrage für diese Ressource

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

Wenn Sie eine solche Angabe machen, wird in der Ergebnisliste das Modell und die Farbe des Fahrzeugs angegeben

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

Wenn Sie einen solchen Befehl eingeben, zeigt die resoce-Methode nur Swift modellbasierte Autos an

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

Wenn Sie dies angeben, erhalten wir die ResourceNotFound-Ausnahme, da ich in der Auto-Ressourcenklasse carmodel als @pathPram deklariert habe. Das heißt, Sie müssen und sollten das carmodel als reQ uri angeben Die Farbe wird nicht übergeben, und die Anforderung wird an die Ressource übergeben. Warum ist die Farbe in der Anforderung optional, da sie @quetyParam lautet?.

1
user4374220

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

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

Abfrageparameter können hierarchische und nicht hierarchische Teilmengen unterstützen. Pfadparameter sind nur hierarchisch.

Ressourcen können mehrere Hierarchien aufweisen. Unterstützen Sie kurze Pfade, wenn Sie breite Untersammlungen abfragen, 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 bei der Komposition nur Pfadparameter - wenn eine Ressource keinen Sinn hat, getrennt von der übergeordneten Ressource, und die globale Sammlung aller untergeordneten Ressourcen an sich keine nützliche Ressource ist.

/words/{id}/definitions
/definitions?word=id   // not useful
1
Steve Mitchell
  1. @QueryParam kann bequem mit der Annotation Default Value verwendet werden, sodass Sie eine Nullzeigerausnahme vermeiden können, wenn kein Abfrageparameter übergeben wird.

Wenn Sie Abfrageparameter aus einer GET-Anforderung analysieren möchten, können Sie einfach den entsprechenden Parameter für die Methode definieren, die die GET-Anforderung verarbeitet, und sie mit der Anmerkung @QueryParam versehen

  1. @PathParam extrahiert die URI-Werte und stimmt mit @Path überein. Und erhält damit den 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 entspricht param1 und p1 entspricht param2. Also für die URI
http://localhost:8080/Restr/rest/msg/4/6,
Wir erhalten das Ergebnis 10.

Im Dienst REST stellt JAX-RS @QueryParam und @FormParam bereit, um Daten von einer HTTP-Anforderung zu akzeptieren. Ein HTTP-Formular kann mit verschiedenen Methoden wie GET und POST gesendet werden.

@QueryParam: Akzeptiert GET-Anforderungen und liest Daten aus der Abfragezeichenfolge.

@FormParam: Akzeptiert die Anforderung POST und ruft Daten aus dem HTML-Formular oder einer beliebigen Anforderung des Mediums ab

1
Amlesh Kumar

Der Grund ist eigentlich sehr einfach. Wenn Sie einen Abfrageparameter verwenden, können Sie Zeichen wie "/" eingeben und Ihr Client muss diese nicht in HTML kodieren. Es gibt andere Gründe, aber das ist ein einfaches Beispiel. Wann ist eine Pfadvariable zu verwenden? Ich würde sagen, wann immer Sie mit IDs zu tun haben oder wenn die Pfadvariable eine Richtung für eine Abfrage ist.

1
Tony

Kurz gesagt,

@Pathparam funktioniert für Werte, die sowohl durch Resources als auch Query String geleitet werden

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

@Queryparam funktioniert nur für Werte, die eine Abfragezeichenfolge übergeben

  • / user? id = 1
0
ArulRajP