18

What is the difference between QueryParam and PathParam in terms of their usage?

I understand that data can be passed to service using both of them. PathParam is the data preceeding ? in the URL and QueryParam are name value data after ?. But I wonder how exactly these are used.

marcok
  • 901
  • 7
  • 13
Anil
  • 565
  • 1
  • 5
  • 14
  • Is your question more about *how* each is used, or do you really mean to ask *when* (i.e., under what circumstances) you would encode something as part of the path vs as a query parameter? – Kevin Welker May 02 '12 at 20:24
  • Kevin, I mean to ask when I should encode somthing as part of the path vs as a query parameter? Thanks in advance.. – Anil Apr 23 '13 at 15:41
  • I am now more interested to know when I should encode something as part of path param vs as a query parameter. – Anil May 12 '16 at 20:13

3 Answers3

52

@QueryParam is used to access key/value pairs in the query string of the URL (the part after the ?). For example in the url http://example.com?q=searchterm, you can use @QueryParam("q") to get the value of q.

@PathParam is used to match a part of the URL as a parameter. For example in an url of the form http://example.com/books/{bookid}, you can use @PathParam("bookid") to get the id of a book.

See this page for an example as used in JAX-RS.

dShringi
  • 1,417
  • 2
  • 18
  • 36
marcok
  • 901
  • 7
  • 13
  • Related question. Hope it helps others. http://stackoverflow.com/questions/25037347/server-side-j2ee-webservice-gets-null-values-on-parameters/25038686#25038686 – Siddharth Jul 30 '14 at 13:54
5

There is probably not a single correct answer to the question in practice, since there are so many different URL schemes in usage out in "the wild". However a helpful way to look at it would be in terms of REST URL processing. In REST (REpresentational State Transfer), the idea is to be able to uniquely identify every resource that you want to provide access to. In a common REST scheme, the path portion of the URL could be thought of as a set of coordinates in N-space (i.e., x, y, z => //myApp/x/y/z) and the query parameters are further specifiers. These further specifiers could be used as search criteria for incomplete path specifications, to return a list of matching resources.

See the following question for more examples of REST URLs.

EDIT: @marcok has a good technical answer, but as your updated comment exposed, you seem more interested in when to choose one over the other. Generally if you are going to be creating "pure" RESTful API, anything that is part of the path should uniquely identify resources by their identity. Oftentimes, this might have your URL ending in an ID value as part of the path to uniquely identify a resource.

However, if your API is directly exposing the ability to search/filter by attributes (probably excluding IDs), you would be more likely to encode that as a query parameter.

These are just examples, and there are different opinions of what entails a good API, and more specifically how purely-RESTful an API needs to be.

Community
  • 1
  • 1
Kevin Welker
  • 7,211
  • 1
  • 33
  • 53
0

@QueryParam: Used to get parameter as key-value pair and based on key in QueryParam can get the value of key from the URL. E.g. example.com/id=searchParam

@QueryParam("id") then value will be searchParam

@PathParam: Used to get the parameters(If parameters contains by URL) from the URL. E.g. abc.com/searchParam/{empId}

@PathParam("empId")