If I'm developing a site that has an integrated API, for example, Laravel, I have a website and an API in the same project
What is the best way to feed the site?
Which best suits your needs? Use this one. And only you can answer this.
Today there is a tendency to use the API and use a frontend web that consumes this API like a desktop or mobile frontend, or some service would do. This has its utility there, and in some cases is the best to do, especially when it is a web application and not a website. Although I am, in general, a web app critic, in most cases, it should either be an application or should not be web. I speak of the frontend .
If it is a website, the traditional approach to rendering the page format is usually done on the server by the MVC view or otherwise.
In this case you do not have to have an extra layer. Only view should be different, one generates JSON and the other generates HTML. If you need a different controller , or you are doing something wrong or you are using a rigid technology that does not meet the need.
Repeating the code in two places should not be an option. Even if the technology and / or architecture does not allow it, you can still abstract the execution into functions in a separate service.
Ideally, the controller should handle both, if it is complicated, at least make it meet its real calling that is to deliver the data to the view .
I see a lot of people writing that the logic of the application should be all there. Even I must have written this at some point. But thinking this is wrong, the controller should be the communication logic of the model with the view. Execution that should not be in the model, must be in a specific part that is attached to the controller, but not directly. Of course if it is simple, it has no use in more than one place, it is not wrong to embed it right there.
Keep in mind that the actions of the controller is defined by how you receive the data and how you send them, it is not the processing of the data. Not directly. There is no repetition, much less hurts the DRY. Use a service.
If the API is the lowest level and the frontend is the highest level, just use the Lego blocks loose on the first, and join them on the second. That's why processing should be separated when you need it.
Today people are so worried about following cake strikes patterns, doing craziness she does not understand architecture, forgetting the basics of the basics.
There are 3 things that have revolutionized programming:
The second in essence is to know how to use functions for your benefit, to avoid repetition, and reach DRY .
Today most of the codes do not meet this, many experienced even realize this. The organization of the code is more important than following the master. Understanding the right level of abstraction helps you more than decorating ready-made templates that may not be the right fit for your problem.
For example, there was initially ASP.NET MVC and ASP.NET WebAPI. Made by the best engineers in the world. It took time to realize that it was all over and there was ASP.NET Core to solve this.
