At some point, when designing functions, whether they be API endpoints, library methods, etc, you need to determine what a "single responsibility" is. There is no definitive best practice on this kind of thing. Every choice has tradeoffs.
How does the functionality differ between each endpoint? If they share a lot of functionality, it makes sense that they are part of the same responsibility.
Let's take basic arithmetic for example. Add, subtract, multiple, and divide. If my only goal was to reduce the number of endpoints, I'd do:
doMath(string operator, string... operands)
But that endpoint should raise some flags. It's very vague and non-descriptive. Not very ideal. I wouldn't even be able to begin using this function/endpoint without accurate and updated documentation. I could go the complete opposite direction, too, and avoid parameters altogether:
It should be pretty obvious why this makes little to no sense. Obviously, we need some sort of middle ground:
add(int op1, int op2)
subtract(int op1, int op2)
multiply(int op1, int op2)
divide(int op1, int op2)
Not a bad solution now. But why are 4 endpoints better than 1? Well, we only need to do basic arithmetic. Therefore, we can be reasonably sure our API won't get super bloated later on. However, if we had an API that literally did every kind of math, maybe it actually would make sense to group the basic arithmetic into a single endpoint or function!
Similarly, if you plan on adding more and more "upload" endpoints, your API will start to get a bit bloated unless you combine them. Of course, how bloated your API can be is up to you and your use-case. Figure out how your clients will consume the API to figure that out.
Ask yourself these questions:
- Do these endpoints share a lot of functionality?
- Is it likely more "upload" functionality will need to be added to the API?
- Does the API do more than uploads?
- Will significant refactoring be required in your consumers if you change the endpoints' signatures in the future?
The more of these questions you can say "yes" to, the more benefit you achieve by reducing the number of endpoints by offloading functionality into your parameter.