I know the difference, but when do I use PathParam or QueryParam? Is the following explanation correct?
If there is a scenario to retrieve the 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
According to this answer in SOen , PathParam is to access the path while QueryParam is to access the < in> query string . To clarify, a complete 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 do not know Jersey, so I can not say when it's appropriate to use one or the other, except that it depends on where the information you want is (in the path or query string). From REST's point of view, the most common is to put names and resource ids in the path itself, whereas arbitrary search parameters can come in query string - so I consider the above explanation to be correct. p>
* Well, almost complete: it is still possible to have usuario:senha@ before source, but I have never seen this being used in practice ...
As already explained by @mgibsonbr, each annotation reads the parameters from different locations.
However, it is important to understand that the Jersey framework implements the JAX-RS API, which is the default 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 in a unique way.
If the employee is a system resource, then it is correct to access it by the GET /employee/{id}. request
Additional parameters, exemplified in the question as paging data, are passed as URL parameters because they are secondary information.