Disclaimer

Despite the question has been scoped as REST, the truth is that it has nothing to do with REST.

Long story short, how to map the request parameters to an specific query language is implementation details. So, for now, lets leave REST aside.

Is the above implementation/concept correct?

For us to say whether is correct or not, we would need to be familiar with the project and its requirements. So far, what we can say is: the solution is not flexible.

Flexible in the sense of scaling in the long run. Every new filter would take you (at least) to modify the controller, the service layer and maybe the data access layer too. From the management standpoint, is hard to buy so much work for so little feature. In other words, the maintenance looks expensive.

Nevertheless, it depends on how often you add new parameters to the query.

So what am I doing wrong here?

You are missing two possible abstractions.

1. The one that maps a dynamic set of request parameters to an specific model of the API.
2. The one that maps the previous model to your specific query language.

Note: Some frameworks makes #1 optional.

Right now the mapping is hardcoded as a if/else block. Too rigid for scaling well.

Instead, It could be similar to:

myController(req,res){

   var query = new QueryParametersMapper(req);

   var page = new PageParametersMapper(req);

   var sort = new SortParametersMapper(req);

   var dataSet = myRepository.find(query, page, sort);

  // etc...
}

What's the correct way of handling queries?

Making the mapping more dynamic. So that new parameters don't necessarily require us to chang the application.

At this point, my first advice would be look for libraries compatible with your framework or programming language.

My second advice would be, pick the one that supports Convention over configuration.

Even if It doesn't prevent you from making changes, at least (I'm sure) the costs of the changes will be lesser than they are now.^*

^{* If we consider the code given as example in the question.}

Disclaimer

Despite the question has been scoped as REST, the truth is that it has nothing to do with REST.

Long story short, how to map the request parameters to an specific query language is implementation details. So, for now, lets leave REST aside.

Is the above implementation/concept correct?

For us to say whether is correct or not, we would need to be familiar with the project and its requirements. So far, what we can say is: the solution is not flexible.

Flexible in the sense of scaling in the long run. Every new filter would take you (at least) to modify the controller, the service layer and maybe the data access layer too. From the management standpoint, is hard to buy so much work for so little feature. In other words, the maintenance looks expensive.

Nevertheless, it depends on how often you add new parameters to the query.

So what am I doing wrong here?

You are missing two possible abstractions.

1. The one that maps a dynamic set of request parameters to an specific model of the API.
2. The one that maps the previous model to your specific query language.

Note: Some frameworks makes #1 optional.

Right now the mapping is hardcoded as a if/else block. Too rigid for scaling well.

Instead, It could be similar to:

myController(req,res){

   var query = new QueryParametersMapper(req);

   var page = new PageParametersMapper(req);

   var sort = new SortParametersMapper(req);

   var dataSet = myRepository.find(query, page, sort);

  // etc...
}

What's the correct way of handling queries?

Making the mapping more dynamic and reusable.

At this point, my first advice would be look for libraries compatible with your framework or programming language.

My second advice would be, pick the one that supports Convention over configuration.

Even if It doesn't prevent you from making changes, at least (I'm sure) the costs of the changes will be lesser than they are now.^*

^{* If we consider the code given as example in the question.}

Disclaimer

Despite the question has been scoped as REST, the truth is that it has nothing to do with REST.

Long story short, how to map the request parameters to an specific query language is implementation details. So, for now, lets leave REST aside.

Is the above implementation/concept correct?

For us to say whether is correct or not, we would need to be familiar with the project and its requirements. So far, what we can say is: the solution is not flexible.

Flexible in the sense of scaling in the long run. Every new filter would take you (at least) to modify the controller, the service layer and maybe the data access layer too. From the management standpoint, is hard to buy so much work for so little feature. In other words, the maintenance looks expensive.

Nevertheless, it depends on how often you add new parameters to the query.

So what am I doing wrong here?

You are missing two abstractions.

1. The one that maps a dynamic set of request parameters to an specific model of the API.
2. The one that maps the previous model to your specific query language.

Right now the mapping is hardcoded as a if/else block. Too rigid for scaling well.

Instead It should be similar to this:

myController(req,res){

   var query = new QueryParametersMapper(req);

   var page = new PageParametersMapper(req);

   var sort = new SortParametersMapper(req);

   var dataSet = myRepository.find(query, page, sort);

  // etc...
}

What's the correct way of handling queries?

Making the solution more dynamic. So that new parameters don't necessarily require us to rebuild the application.

At this point, my first advice would be look for libraries compatible with your framework or programming language.

My second advice would be, pick the one that supports Convention over configuration.

Even if It doesn't prevent you from making changes, at least (I'm sure) the costs of the changes will be lesser than they are now.^*

^{* If we consider the OP's example.}

Disclaimer

Despite the question has been scoped as REST, the truth is that it has nothing to do with REST.

Long story short, how to map the request parameters to an specific query language is implementation details. So, for now, lets leave REST aside.

Is the above implementation/concept correct?

For us to say whether is correct or not, we would need to be familiar with the project and its requirements. So far, what we can say is: the solution is not flexible.

Flexible in the sense of scaling in the long run. Every new filter would take you (at least) to modify the controller, the service layer and maybe the data access layer too. From the management standpoint, is hard to buy so much work for so little feature. In other words, the maintenance looks expensive.

Nevertheless, it depends on how often you add new parameters to the query.

So what am I doing wrong here?

You are missing two possible abstractions.

1. The one that maps a dynamic set of request parameters to an specific model of the API.
2. The one that maps the previous model to your specific query language.

Note: Some frameworks makes #1 optional.

Right now the mapping is hardcoded as a if/else block. Too rigid for scaling well.

Instead, It could be similar to:

myController(req,res){

   var query = new QueryParametersMapper(req);

   var page = new PageParametersMapper(req);

   var sort = new SortParametersMapper(req);

   var dataSet = myRepository.find(query, page, sort);

  // etc...
}

What's the correct way of handling queries?

Making the mapping more dynamic. So that new parameters don't necessarily require us to chang the application.

At this point, my first advice would be look for libraries compatible with your framework or programming language.

My second advice would be, pick the one that supports Convention over configuration.

Even if It doesn't prevent you from making changes, at least (I'm sure) the costs of the changes will be lesser than they are now.^*

^{* If we consider the code given as example in the question.}