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 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:
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.