为什么要通过 .htaccess 文件与路由器（前端控制器）路由 Restful 请求？答案

【问题标题】：Why route Restful requests through a .htaccess file vs a router (front controller)?为什么要通过 .htaccess 文件与路由器（前端控制器）路由 Restful 请求？
【发布时间】：2014-01-17 15:52:59
【问题描述】：

背景故事：
我正在尝试使用 REST 架构构建一个 API，其中性能是 numero uno。

团队拥有解决方案（来自以前的项目）的经验，该解决方案通过 .htaccess 文件路由所有调用，然后转发到正确的控制器（.htaccess->controller(resource)->response）。这相当快，但代码不是很灵活，也不符合 SOLID 原则（总的来说，我觉得很难使用，简单明了）。

当前模型基于http://coreymaynard.com/ 示例：

.htaccess file:
RewriteRule api/logins/(.*)$ api/controllers/Logins.php?request=$1 [QSA,NC,L]
Controller:
logins->get_login; logins->post_login; etc etc.  Extends a base class that reads the request and builds what method to execute.

我一直在认真研究 API 解决方案和框架； Slim、Phalcon、Laravel 等，以及一些基本的（并且大部分是有偏见的）性能测试，用于与 adhoc 系统进行比较。 adhoc 的表现优于 Slim，并且与 Phalcon 并驾齐驱——我们不会选择 phalcon，因为它在团队中不太受信任。所以我们的解决方案是编写一个最小的 php 应用程序。我不想使用现有的 API 系统，做一些类似于前端控制器的事情。

我非常喜欢 Slim 构建资源路由的方式，如下所示：

$app = new Slim/Slim();
//Add Get Route
$app->get('/my/route', Function/Map to Object/Do something else);

对我来说，这是可读的、易于维护的，甚至更容易扩展。然后我在网上发现了这个小宝石： Small and Fast Controller with PHP

基于这些示例，我制作了一个路由控制器的原型并与我的团队共享。

问题：

1) 当我添加额外的路线时，我会看到什么样的性能影响？我对以这种方式执行路线的信息不满意（非常程序化，由异常处理停止），我也没有做出假设的经验。

2a) 我是否对 .htaccess 路由方法过于愤世嫉俗？解析 .htaccess 文件所产生的服务器开销是否真正值得关注？

2b) 有没有人有过以这种方式构建 php 应用程序或 REST 应用程序的经验？

一如既往，感谢您抽出宝贵时间阅读和回复。

更新：我们正在迁移到 Nginx 服务器，这意味着通过 Nginx 的配置定义路由的访问受限，并决定使用前端控制器来定义我们的路由。

【问题讨论】：

标签： php rest restful-url

【解决方案1】：

“更新：我们正在迁移到 Nginx 服务器，这意味着通过 Nginx 的配置定义路由的访问受限，并决定使用前端控制器来定义我们的路由。”

这告诉我，通过 .htaccess 定义路由是不明智的。您的前端控制器理论上应该可以在 nginx 或 apache 上运行而无需修改，并且您的应用程序将继续按预期运行。我相信你做出了正确的决定。

【讨论】：