我想构建一个同时使用 Web 和 API 部分的 Laravel 应用程序。常见的（也是我的）问题是是否使用单独的控制器。
有 2 个选项：
独立控制器Laravel API 控制器结构？ https://stackoverflow.com/questions/20182960/laravel-api-controller-structure
使用一个控制器并检查请求类型（是 Ajax，或取决于请求链接）并返回 JSON 或 HTML。适用于 API 和非 API 使用的 Laravel 资源控制器 https://stackoverflow.com/questions/17899609/laravel-resource-controllers-for-both-api-and-non-api-use?rq=1
那些持有第一意见的人并没有解释 DRY 问题的解决方案 - 除了返回语句（JSON 或 HTML 视图）之外，Web 和 API 控制器将是相同的。但由于大多数帖子建议单独的控制器，我怀疑我不了解 DRY 问题解决方案。
我不认为第二种方法有任何缺点。但人们会说类似的话
如果您只使用一个控制器，您很快就会得到一个包含数千行的混乱类。这不仅不能很好地扩展，而且对你和你的队友来说也很难合作。
请解释一下第一种方法（单独控制器）的 DRY 问题解决方案以及第二种方法（单个控制器）中可能存在的水下岩石
请解释哪种方法更可取。
我认为这是一个很好的问题，我也很想看到答案。
我可以看到这两种方法的论点。然而，我会创建和维护单独的控制器，同时使用服务在控制器之间共享公共逻辑，并且知道这永远不会改变。
例如，如果您允许用户上传头像图像。我会将这样的逻辑放入一个服务中，并在两个控制器中使用该服务。
在我看来，这种方法的原因是 Web 和 API 逻辑可能会有所不同，因此更容易迭代每个逻辑而不影响另一个逻辑。
如果这不太可能，那么我仍然会创建单独的路由，但将它们都指向相同的控制器，这样如果将来确实发生变化，您可以简单地将 API 路由重新指向它们自己的控制器。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
