@dennisprudlo I’m not a fan of this approach, as it then means practically every controller action is now going to have that if/else statement, which is going to be repetitive and isn’t very “DRY”.
There’s nothing wrong with having one controller class serve web requests and another serve API requests. There are patterns you can use to DRY out the business logic: repositories or service classes for example.
It also means your web and API requests are very tightly coupled. You can’t use different query string filters in your web requests from your API requests now. If you want to use different filters in web requests vs. API requests, guess what: more conditional logic.
Another drawback is, web requests usually have more data than an API request. So you might have filters in your web UI, with options retrieved from the database. If you’re reusing your web controller for API requests, then API requests are going to invoke this query as well even if the options aren’t actually presented. You also can’t do things like use different pagination limits for web and API requests (i.e. you might want to show 30 items at a time in your API, but only 10 at a time in your web UI).
The best rule of thumb is to not try and be too “clever” when it comes to code. Premature optimisation and overzealous DRY-ing out of code can just lead to code that’s more difficult to maintain and work with. It’s always good to strive for DRY code, but here I think you’ve looked at DRY-ing it at the wrong level: you’re looking to DRY out the symptoms (the controllers) rather than the actual cause (the business logic). Stick to conventions, as they don’t tend to come about by accident.