Diferença entre controller sistema e controller api

Olá, Rafael!
Tudo bem?

Sim, você pode usar Services e Repositories na aplicação também, exatamente como fizemos na API;

Foi essa mesmo a sua pergunta?

É pq eu gostaria de entender melhor quando usar uma abordagem e quando usar outra.

Mesmo tendo entendido o conceito, ainda não consegui imaginar uma maneira de utilizar a abordagem da API, nos vídeos você fala em relação a mudança dos dados tipo doctine/eloquent, mas acredito que isso seja um universo bem incomum, não?

Pelo o que eu entendi até o momento em relação ao laravel, a forma mais prática e limpa seria usar o controller com repository setando o objeto e caso a regra de negocio seja extensa fazer um service pra deixar o controller mais enxuto. Meu entendimento está correto?

Sim, é MUITO raro para não dizer quase inimaginável esse cenário.

A ideia de respositories também é organizar, e centralizar a gestão de dados em um único local. Pensa que precisa fazer uma query bem complexa, onde ela deve ficar?
No controller? Nem pensar. No model? Pode ser, mas vai deixar o model muito cheio. No repository? SIMMM! =D

-----

Sobre o seu raciocínio, ele está perfeito, é exatamente isso.

Se ainda tiver dúvidas amigo, pode me perguntar o que quiser, até esclarecer tudo.

Show, obrigado pelos esclarecimentos.

Eu entendi que essa maneira de interfaces e repositories é uma convenção no laravel, vi em outros cursos seu e também muito em artigos gringos também. Mas a minha opinião pessoal até o momento é que é muita estrutura pra alguns projetos que as vezes se torna confuso essa implementação.

Sobre o que você falou da regra de negocio, nesse curso do larafood abriu minha mente ainda mais pra outras opções, como por exemplo Observers em regras de cadastro/alteração e a camada de Services. Então, por exemplo, caso houvesse uma query complexa eu poderia fazê-la no Service para deixar o controller mais enxuto, igual foi demonstrado na aplicação.

Então, utilizando o service nessa situação, substituiria a função do repository e eu não precisaria fazer a implentação da interface. 

Em resumo, essa maneira foi a que eu mais me 'acostumei' em estruturar o codigo, essa forma de fazer, de alguma forma 'fere' algum psr do php/laravel?

Sim, super concordo com você, para projetos pequenos na realidade não faz nem sentido trabalhar com isso, porque gera muita parametrização inicial.

-----

A camada service fica a lógica, como foi no caso do LaraFood para a parte de gerar pedido (new order), tem muitos processos (desde calcular os preços até formatar os produtos), nesse caso o nosso controller ficou enxuto, e service ficou com a lógica e o repository ficou com a parte de banco de dados. Se tiver uma query bem grande, onde fica? No repository.

A ideia de repository e services são diferentes. Service layer: lógica, repository: dados.

Show, carlos. Obrigado pelos esclarecimentos

Show, 
Eu estou aprendendo muito , mais muito mesmo.

Tenho um sistema de escola infantil, agora vou ter q reescrever todo, depois desse curso, principalmente a parte de API para o APP

Obrigado.