Apart from MacWorks, I don't believe any of these are answering the original question which is how to expose similar functionality across both an api and a web front end. MacWorks' idea of using a query arg would work (as would most things given enough pain and effort) but it's not ideal and would normally be used as a form of api content negotiation (in which case just use http content negotiation) and not for use in a case like this.

Unsurprisingly this situation is very common. Lots of sites expose their data over an api and also have their own front end over the top. They certainly aren't writing the whole thing twice! The root of the problem here is that you're thinking in terms of controllers and adding all of the necessary logic to them, the end result of which is a bad case of what is known as The Fat Controller (Thomas the Tank Engine has been a big MVC fan for years). Fat controllers aren't bad in themselves but when you're trying to implement multiple presentations over the same data/logic it's a dangerous trap to fall into. Assuming a simple case of authenticating a user, querying some data in a db, maybe generating an email, some diagnostic logging, etc... putting this all in the controller is fine for a quick and dirty site or when you're doing a short proof of concept but you'll eventually hate yourself for it.

A much better approach commonly used is the notion of command objects which encapsulate all of the necessary request context data and trigger the processing of your exposed actions, returning the result back to the controller (see here for a great course/intro - https://laracasts.com/series/commands-and-domain-events. When you've finished watch every other video Jeremy has produced, they're all solid gold!). In your case the command result is then simply returned to the API controller for serialization on the wire.

The web controller can generate and post the exact same command and return whatever is appropriate in this case, e.g. passing the command response to a view and returning the rendered html.

The end result is you have a thin routing/controller layer just posting command objects into a bus and returning the result on the wire in whatever format you need. If you need to modify some logic or add additional steps to your process, you have a nice clean architecture in which to make these changes and instantly see the results in both API & Web simultaneously.

Finally, yes of course you could have a fat API controller design, make one big giant class handling all of your logic, delegate your web controller calls to this, decode the json, pass it to the view, and so on.. however that's layering one bad design on top of another and another and given one of your objectives is to learn, I suggest learning good practices from the start. Like all things, development bad habits are just as hard to break as any other.

HTH