Question

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

团队拥有解决方案（来自之前的项目）的经验，该解决方案通过.htaccess文件路由所有呼叫，然后转发到正确的控制器（.htaccess-＆gt; controller（资源） - ＆gt;响应）。这是非常快的，但代码不是很灵活，也不符合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系统进行比较。特别表现优于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配置定义路由的访问受限，并决定在前端控制器上定义我们的路由。

Answer 1

“更新：我们正在转向Nginx服务器，这意味着通过Nginx配置定义路由的访问权限有限，并决定在前端控制器上定义我们的路由。”

对我来说，通过.htaccess定义路线是不明智的。您的前端控制器理论上应该在没有修改的情况下使用nginx或apache，并且您的应用程序将继续按预期运行。我相信你做出了正确的决定。

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

1 个答案: