When do I use Pathparam or Queryparam?

Asked

Viewed 4,191 times

2

I know the difference, but when do I use Pathparam or Queryparam? It is correct the following explanation?

If there is a scenario to Retrieve a record based on id, for example you need to get the Details of the Employee Whose id is 15, then you can have Resource with @Pathparam.

GET /employee/{id}

If there is a scenario Where you need to get the Details of all Employees but only 10 at a time, you may use query param 

GET /employee?start=1&size=10
web-service api

  • This is not something native to Java, right? I assumed given similar question in Soen that it comes to the Jersey framework, but if I’m mistaken please reverse my edit.

  • Thank you, I made the correction! The correct tag is "web-service"

2 answers

1


According to that answer in Soen, PathParam serves to access the path while QueryParam serves to access the query string. Clarifying, a full URL* has the following parts:

http    :// google.com : 80    /foo/bar/baz ?a=10&b=20     #seção

esquema :// origem     : porta caminho      query_string   fragmento

I don’t know Jersey, so I can’t tell you when it’s appropriate to use one or the other, except that it depends on where the information you want is (in the way or on query string). From the REST point of view, the most common is to put resource names and ids in the path itself, while arbitrary search parameters can come in the query string - so that I consider correct the explanation cited.

* Well, almost complete: it is still possible to have usuario:senha@ before the origin, but I’ve never seen it used in practice...

1

As already explained by @mgibsonbr, each annotation reads the parameters of different locations.

However, it is important to understand that the Jersey framework implements the JAX-RS API, which is the standard Java API for Restful Web Services. So the correct thing is to always follow the REST architecture standards.

In this case the explanation is correct, because in REST it is understood that the resource identifiers are in the path of the URL, identifying that resource uniquely.

If the employee (Employee) is a system resource, so it is correct to access it by request GET /employee/{id}.

Additional parameters, exemplified in the question as pagination data, are passed as URL parameters because they are secondary information.

Browser other questions tagged web-service api

You are not signed in. Login or sign up in order to post.