17

I want to build a Laravel application which users both web and API parts. The common (and mine as well) question is whether to use separate controllers or not.

There are 2 options:

  1. Separate controllers Laravel API controller structure?

  2. Use one controller and check the request type (is Ajax, or depending on the request link) and return either JSON or HTML. Laravel resource controllers for both API and non-API use

Those who have the 1-st opinion doesn't explain the DRY problem solution - web and API controllers would be the same except the return statement (JSON or HTML view). But since most post recommend to separate controllers I suspect I don't understand something about the DRY problem solution.

I don't see any disadvantage of the second method. But people say something like

If you use only one controller, you will end up soon with a messy class with thousands of lines. Not only this is not going to scale well, but it will be hard to work with for you and your teammates.

Please explain me the DRY problem solution for the first approach (separate controllers) and the possible underwater rocks in the second approach (single controller)

Please explain which approach is preferable.

Community
  • 1
  • 1
AHeavyObject
  • 562
  • 1
  • 7
  • 18
  • 2
    Repository pattern separates the data access logic and maps it to the business entities in the business logic. Make one common repository for both web and api controller. – sumit Apr 26 '17 at 23:43
  • @sumit I'd upvote this more than once if I could. – fubar Apr 26 '17 at 23:43
  • @sumit Wouldn't the controller methods be the same disregarding whether using repositories or not? Except the return part. Yes, small controlles, but almost the same? – AHeavyObject Apr 26 '17 at 23:59
  • check this https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/ – sumit Apr 27 '17 at 00:01
  • @sumit I have read this article before and have reread it again. It tells of higher level of abstraction for getting data. But both API and WEB methods should have the same look (get data with a Repository) but different return statement. So I don't see how this helps with my question. Even if methods consist of 2 lines (like in the article) is this a reason to repeat them in different controllers replacing the retrurn statement? – AHeavyObject Apr 27 '17 at 00:27
  • I’m voting to close this question because it's opinion based and would be better suited on the Software Eng SE – Chuck Le Butt Feb 08 '23 at 18:22
  • Using the Repository Pattern with Laravel is the devil – Chuck Le Butt Feb 08 '23 at 18:24

1 Answers1

6

I think this is a great question, and I too am keen to see the responses.

I can see the arguments for both approaches. I however would create and maintain separate controllers, whilst using services to share common logic between the controllers where it is known that this will never change.

For example, if you allow users to upload avatar images. I would put such logic in a service and consume this service in both controllers.

The reason for this approach in my mind, is that the web and API logic may diverge and it would therefore be easier to iterate each without impacting the other.

If this is unlikely, then I would still create separate routes, but point them both at the same controllers, so that if it did change in the future, you can simply re-point the API routes to their own controllers.

fubar
  • 16,918
  • 4
  • 37
  • 43
  • you say > For example, if you allow users to upload avatar images. I would put such logic in a service and consume this service in both controllers. I don't understand. Wouldn't calling the service be the same in both controllers? Wouldn't something like ` $data = $this->userService->getAll($resourceOptions);` be the same in both controllers? Please explain. – AHeavyObject Apr 26 '17 at 23:26
  • Exactly. The calls to the service would likely be identical, but perhaps with different arguments. However this would mean you're keeping your code DRY by not duplicating all of the logic in both controllers. Instead, it's centralised in the service. – fubar Apr 26 '17 at 23:28
  • Sorry, I don't understand. There should still be the same methods in both controllers. They would have the same service call part and will differ only in return part (JSON or HTML). So we violate DRY. But you say we should divide controllers. Do I misunderstand something? Maybe the key idea of separate controllers is that in the future the methods would demand more difference then return part sooner or later (though I don't see why). This would explain the idea of separation. – AHeavyObject Apr 26 '17 at 23:35
  • I would either use the same controller and change response based on request, but have separate named routes for web and API pointing to the same controller actions *or* create entirely separate controllers with duplicated actions, and consolidate logic into services where possible. – fubar Apr 26 '17 at 23:45
  • This is quite my question - which or this EITHER/OR to use and why. (-: – AHeavyObject Apr 27 '17 at 00:01
  • I would want some form of separation. If the logic is identical for both web and API, I'd go with separate routes to facilitate easily splitting the logic later. If it's different, I'd go with separate controllers. – fubar Apr 27 '17 at 00:02
  • So the same controller with different routes to it. And split controllers only if the logic start to differ. This makes sense. – AHeavyObject Apr 27 '17 at 00:08