Search code examples
javajerseyjersey-client

Using GET REST call in order to find all the related objects


I am using Jersey as my RESTful Web Services framework. I have made 2 new @GET REST calls in order to search objects in the database. Those REST calls should serve 2 different components.

  • The first component has the user_id in its details.
  • The second component has the email in its details.

The email and the user_id are 2 different unique identifiers.

One option is to enable 2 different @GET REST calls with different paths such as:

".../api/users/search/id/:user_id"
".../api/users/search/email/:email"

In order to make is as simple as possible and much more general for future demands, I am looking for the way to merge those 2 REST calls to 1 path with different identifiers on in its QueryParam.

After searching for a good example followed by the best practices for such REST calls, I am not sure if such a merge is a good practice, or not.

The main issue I am not sure about is how to build the path as generic as can be. The questions are:

  1. Is it a good practice to merge those 2 different paths to 1 path in 1 REST call? if yes, please provide an example.
  2. If it is a bad practice to merge those paths, how should I handle future features requests to search using new identifiers? the thinking of building new REST call for each identifier sounds problematic.

Solution

  • Well, one solution would be to add new queryParameters to the uri and thus enabling the users to use the same resource but with new parameters like for instance: /uri/search/[email protected]&user_id=userAdam.

    Then you will on the server side need to take care of all these different scenarios in the same method. Thus you dive into the if/else/switch type of thing.

    You will then have to handle to JSON objects returned. Obviously if you have a contract you need to follow it, thus if the client expects completely different responses it is hard to deliver them from one resource. So if the email query response is something significantly different than the user_id query response it might be hairy returning it from the same resource.

    My 5 cents. Maybe I misunderstood you.