当URI可以动态解析时,路由器有什么好处？

Question

我正在尝试做出架构决策,我担心在设计基本REST API /框架时,我遗漏了一些关于URL路由/映射的重要信息.

创建通常在REST API框架中看到的路由类,这需要人们手动将URL映射到类,以及类方法(操作),这类似乎无法封装问题.当这一切都可以通过动态解析URL并拥有自动路由器或首页控制器来确定.

GET https://api.example.com/companies/

收集资源,获取所有公司的列表.

GET https://api.example.com/companies/1

通过ID获取单个公司.

所有似乎都遵循模板:https://api.example.com/<controller>/<parameter>/

好处1:URL解耦和抽象

我假设具有典型路由类的一个好处是,您可以从资源/物理类中分离或抽象URL.因此,如果您愿意,可以使用任意URL GET https://api.example.com/poo/来代替GET https://api.example.com/companies/所有公司.

但是在我看到的几乎所有示例和用例中,希望有一个匹配所需控制器,动作和参数的URL,1:1.

另一个可能的好处是,使用URL映射和典型路由器可以更容易地实现资源中的集合资源或嵌套资源.例如:

GET https://api.example.com/companies/1/users/

要么

GET https://api.example.com/companies/1/users/1/

可能是相当具有挑战性拿出一个模式,它可以动态地分析该知道为了得到数据,使用什么参数,并在使用它们所谓的控制器.但我想我已经拿出,可以使动态这项工作的标准方法.

而手动映射这将很容易.

我可以重新路由GET https://api.example.com/companies/1/users/到用户控制器,而不是公司的控制器,绕过它,只需设置参数"1"是该公司的ID为WHERE子句.

效益1.1:与物理路径无关

受益1,增编将是一个开发人员可以彻底改变URL方案和文件夹结构,在不影响API,因为一切都抽象映射.如果我选择移动文件,文件夹,类别,或重命名,它应该只是改变映射/路由的问题.

但仍然没有真正得到这个好处要么,因为即使你有你的整个API移动到另一个位置,在固定的.htaccess一个微不足道的变化这立即.

所以这:

GET https://api.example.com/companies/

至

GET https://api.example.com/v1/companies/

不会影响代码,即使是最轻微的.即使使用动态路由器.

好处2:控制暴露的功能

我想象一个典型的路由器类的另一个好处是,通过一个只解释和解析URL的动态路由器,可以控制你想要向API使用者公开的功能.如果你只是动态地做所有事情,你就会放弃你的裤子,自动让你的消费者访问整个系统.

我认为这是动态路由器的一个可能的好处,因为您不必手动定义并将所有路由映射到资源.它就在那里,自动完成.为了解决暴露问题,我可能会通过定义不允许API使用者使用的功能的黑名单来做相反的事情.我可能会更有效,定义黑名单,然后使用映射定义每个可用资源.再说一遍,我想它也风险更大.你甚至可以做白名单......这类似于典型的路由器,但你根本不需要任何扩展逻辑.在将URL传递给动态路由器之前,它只是系统将检查的URL列表.或者它可能只是动态路由器类的私有属性.

好处3:当HTTP方法不适合比尔时

我看到典型的路由器闪亮的一种情况是,您需要执行与现有资源冲突的操作.让我解释.

假设您要通过在用户类中运行登录功能来验证用户身份.但是现在,您无法POST https://api.example.com/users/使用凭据执行,因为这是为添加新用户而保留的.相反,您需要以某种方式在您的用户类中运行登录方法.你也不想使用它们POST https://api.example.com/users/login/,因为那时你使用的是除HTTP方法之外的动词.但是,对于典型的路由器,您可以直接映射它,如前所述.简单.

url => "https://api.example.com/tenant/"
Controller => "users"
Action => "login"
Params => "api_key, api_secret"

但是,我再一次看到了一个看似合理的选择.我可以创建另一个控制器,称为登录或租户,实例化我的用户控制器,并运行登录功能.所以消费者可以只凭POST https://api.example.com/tenant/凭证和责任.验证.

虽然,为了让这个替代工作,我将不得不物理创建另一个控制器,当使用URL映射器时,我不需要.但是,这种关注,功能和资源的分离也非常好.但是,也许这是主要的权衡,你宁愿只定义一个URL路由,还是必须为你遇到的每个细微差别创建新的类？

我没有看到或理解什么？我在这里错过了一个核心概念,只是无知吗？拥有典型的URL映射和路由类和功能有什么好处,我只是不知道,或者我几乎得到了这个？

Answer 1

您描述的路由的许多好处都是正确的，您所说的有关物理映射的一些内容也是正确的。我想提供一些经验/实用信息，这些信息影响了我过去几年对路由器的看法。

1. 首先，当您根据 MVC 设计模式构建应用程序时，url 的动态解析效果很好（大多数时候）。例如，我曾经使用 Kohana 构建了一个非常大的应用程序，它是一个分层 MVC 框架，它允许您扩展控制器和模型以便制作嵌套 url。总的来说，这是很有意义的。但很多时候，围绕一次性 URL 的需要来构建整个类和模型系统以使应用程序更具功能性并没有多大意义。但有时 MVC 不是您正在使用的设计模式，因此它不是 API 的定义功能，而路由在这种情况下非常有用。通过使用具有很大结构自由度的框架（例如 Slim 框架或 Express.js），人们可以很容易地看到这个问题。

2. 比人们想象的更常见的是，除了可供使用的主要 RESTful 端点之外，功能齐全的 API 还具有 RPC 元素。当消费者装饰现有资源方法映射时，这些附加功能不仅更有意义。这种情况往往发生在您构建了大部分应用程序并覆盖了大部分基础之后，然后您意识到您想要添加一些与资源相关的小功能，但这些功能并不适用完全适合创建/读取/更新/删除类别。当你看到它时你就会知道。

3. 它确实不能被低估，更安全的是不要对控制器和模型的实际结构进行黑客攻击，添加、删除、更改事物，其唯一目的是添加本质上不遵循相同规则的端点。其他控制器方法（API 端点）。

4. 另一件非常重要的事情是，您的 API 端点实际上比我们通常意识到的更容易被修改。我的意思是，您可以在周一对端点的结构感到满意，然后在周五，您会收到上面发送的任务，说您需要将所有这些 API 调用更改为其他结构，那就是美好的。但是，如果您有一个大型应用程序，那么当您使用的框架对类命名、文件命名、物理命名有严格的规则时，这需要非常非常大量的文件重命名、类重命名、链接以及各种非常容易损坏的代码。文件路径结构和类似的东西......想象一下，更改类名以使其与新结构一起工作，现在您必须寻找实例化旧类的每一行代码，并更改它。此外，在这种情况下，可以说问题在于您的代码与 API 的 url 结构紧密耦合，并且如果您的 url 需要更改，则不太可维护。

无论哪种方式，您确实应该决定什么最适合特定的应用程序。但是您使用路由器的次数越多，您就越会明白它们为何如此有用。