There's nothing specific to API testing in this question; this is the case whenever you have a function that takes multiple inputs.

So, first, you'd need to understand how the API interacts with the backend service. Is it actually doing anything, or is it just passing a call on to some other program? If so, was any testing of that program done? If the other program has been tested, you may want to take the risk of doing minimal testing of the API, and just verify that the data that you get back from the program is the same as you get from the API call. If the API call is doing compositing or the like, or the function hasn't been tested before, you can't take this approach.

If you've decided you do need to test the API call, then you'd test it like you'd test any function with many inputs. You'd want to test limits and null values for each input, and some expected good inputs as well. And then you have to worry about the combinatorial explosion issue; for that, I'd first point you here: Should A Formal Test Plan For Dynamic String Testing Include All Combinations?. Then, I'd suggest looking into combinatorial test design if you feel the need to go further. But realize that the more inputs that are required to trigger a bug, the less likely it is for that bug to be hit.

Beyond that, you also may need to worry about different access patterns/response time requirements than the function itself had. You probably should do some amount of performance testing, to find bottlenecks. You may want to do security testing, but I'd argue that that's better for specialized security testers to do. How far to go in any of these areas depends on how important the REST API is, what data it's protecting, and so on.

Most of the question (and answer) isn't specific to API testing; combinatorial explosion is a problem whenever you have a function that takes multiple inputs.

So, first, you'd need to understand how the API interacts with the backend service. Is it actually doing anything, or is it just passing a call on to some other program? If so, was any testing of that program done? If the other program has been tested, you may want to take the risk of doing minimal testing of the API, and just verify that the data that you get back from the program is the same as you get from the API call. If the API call is doing compositing or the like, or the function hasn't been tested before, you can't take this approach. Also, note that exposing an internal function to the outside world may change how, or how often, it gets used.

If you've decided you do need to test the API call, then you'd test it like you'd test any function with many inputs. You'd want to test limits and null values for each input, and some expected good inputs as well. You'd want to specifically test any documented requirements (ie, input X should always return Y, or always throw an exception). And then you have to worry about the combinatorial explosion issue; for that, I'd first point you here: Should A Formal Test Plan For Dynamic String Testing Include All Combinations?. Then, I'd suggest looking into combinatorial test design if you feel the need to go further. But realize that the more inputs that are required to trigger a bug, the less likely it is for that bug to be hit.

Beyond that, you also may need to worry about different access patterns/response time requirements than the function itself had. You probably should do some amount of performance testing, to find bottlenecks. You may want to do security testing, but I'd argue that that's better for specialized security testers to do. How far to go in any of these areas depends on how important the REST API is, what data it's protecting, and so on.