Qual atende melhor a sua necessidade? Use essa. E só você pode responder isso.

Hoje há uma tendência ao uso de API e usar um frontend web que consome essa API igual um frontend desktop ou mobile, ou algum serviço faria. Isso tem lá sua utilidade, e em alguns casos é o melhor a fazer, especialmente quando é uma aplicação web e não um website. Ainda que eu seja, de forma geral, um crítico da aplicação web, na maioria dos casos, ou não deveria ser uma aplicação ou não deveria ser web. Falo do frontend.

Se for um website geralmente a abordagem tradicional de trabalhar com a renderização do formato da página ser feita no servidor pela view do MVC ou outra forma.

Nesse caso não tem porque ter uma camada extra. Só a view deve ser diferente, uma gera JSON e a outra gera HTML. Se precisa de um controller diferente, ou está fazendo algo errado ou está usando uma tecnologia rígida que não atende bem a necessidade.

Repetir o código em dois lugares não deveria ser opção. Mesmo que a tecnologia e/ou arquitetura não permita, ainda pode abstrair a execução em funções em um serviço separado.

Idealmente o controlador deveria atender bem ambos, se for complicado, pelo menos faça ele atender sua real vocação que é entregar o dado para a view.

Eu vejo muita gente escrevendo que a lógica da aplicação deve ser toda ali. Até eu mesmo devo ter escrito isto em algum momento. Mas pensando bem, isso está errado, o controller deve ser a lógica de comunicação do modelo com a visão. Execução que não deve estar no modelo, deve estar em uma parte específica que está ligada ao controlador, mas não diretamente. Claro que se é simples, não tem utilização em mais de um lugar, não é errado embutir ali mesmo.

Tenha em mente que as actions do controlador é definido por como recebe os dados e como os manda, não é o processamento dos dados. Não diretamente. Aí não tem repetição, muito menos fere o DRY. Use um serviço.

Se a API é mais baixo nível e o frontend é mais alto nível, é só usar os bloquinhos de Lego soltos na primeira, e juntá-los na segunda. Por isso que o processamento deve ser separado, quando precisa.

A arte perdida de abstrair

Hoje as pessoas estão tão preocupadas em seguir receitas de bolo padrões, fazer maluquices que ela não entende arquitetura, que esquecem do básico do básico, do fundamento.

Existem 3 coisas que revolucionaram a programação:

• A escrita de código em alto nível
• A modularização
• O gerenciamento automático de memória

O segundo em sua essência é saber usar funções para seu benefício, para evitar repetições e alcançar o DRY.

Hoje grande parte dos códigos não atendem isso, muitos experientes sequer percebem isso. A organização do código é mais importante que seguir o mestre. Entender o nível correto de abstração te ajuda mais que decorar modelos prontos que talvez não seja o mais adequado para seu problema.

Por exemplo, inicialmente existia o ASP.NET MVC e o ASP.NET WebAPI. Feitos pelos melhores engenheiros do mundo. Demorou para perceberam que era tudo repetido e aí fizeram o ASP.NET Core para resolver isso.