Laravel API 控制器结构？答案

【问题标题】：Laravel API controller structure?Laravel API 控制器结构？
【发布时间】：2013-12-09 13:58:24
【问题描述】：

用户 api 的控制器结构中哪一个有意义

每个 api 版本的 UI 和 API 单独控制器

/app/controllers/UsersController.php
/app/controllers/api/v1/ApiUsersController.php

或

UI 和 API 的单独控制器并在代码中处理版本控制

/app/controllers/UsersController.php
/app/controllers/api/ApiUsersController.php

或

使用单个控制器，检测路由器内的 /api/ 调用。根据 url 返回 html/json。

/app/controllers/UsersController.php

【问题讨论】：

【解决方案1】：

毫无疑问，第一个选项是三个选项中最好的，原因是可扩展性和维护。

如果你只使用一个控制器，如第三种方法所建议的那样，你很快就会得到一个包含数千行代码的凌乱类。这不仅不会很好地扩展，而且对你和你的队友来说也很难合作。

第二个选择比第三个好，但仍然不是最好的。从一开始就支持 API 版本控制是一种更好的做法，它将使您的路由、文件和命名空间更有条理。

顺便说一句，只要命名空间正确，您也可以使用UserController，而不是将其命名为ApiUserController。因此，您可以同时存在 \UserController 和 Api\V1\UserController。

【讨论】：

Manuel，你能解释一下为什么要使用不同的控制器，如果所有的区别都是输出 JSON 或 HTML。至于我拥有相同的控制器，只有不同的返回语句是违反 DRY 的。我一定没有考虑到什么。你的意思是说，Web/API 对应的方法迟早会变得比我想象的更繁重吗？
我想，这只是因为如果您的 API 控制器中有一种方法（例如返回 json 的索引），但您希望带有索引的 Web 控制器返回一个 vew，那么它不会得到试图将请求与需要 json 的请求分开的逻辑混乱，并且只能有明确分开的控制器来处理每件事。保留您的代码。

【解决方案2】：

个人意见。我更喜欢第一种选择。多合一应用，并通过命名空间进行版本控制。

【讨论】：