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

Question

我正在尝试做出架构决策，但我担心在设计基本的 REST API/框架时我会遗漏一些关于 URL 路由/映射的重要内容。

创建路由类等通常在 REST API 框架中看到的类，需要手动将 URL 映射到类和类方法(操作)，这似乎无法封装问题。当这一切都可以通过动态解析 URL 并具有自动路由器或首页 Controller 来确定时。
GET https://api.example.com/companies/
获取所有公司列表的集合资源。
GET https://api.example.com/companies/1
通过 ID 获取单个公司。

这一切似乎都遵循模板:https://api.example.com/<controller>/<parameter>/
好处一:URL解耦和抽象

我认为拥有典型路由类的纸上好处之一是您可以从资源/物理类中解耦或抽象 URL。所以你可以有任意的 URL，比如 GET https://api.example.com/poo/而不是 GET https://api.example.com/companies/如果您愿意，它可以获取所有公司。

但在我见过的几乎所有示例和用例中，希望有一个与所需 Controller 匹配的 URL ， Action 和参数，1:1。

另一个可能的好处是，使用 URL 映射和典型路由器可能更容易实现资源中的集合资源或嵌套资源。例如:
GET https://api.example.com/companies/1/users/
或者
GET https://api.example.com/companies/1/users/1/
想出一个可以动态解析它以了解调用哪个 Controller 以获取数据、使用哪些参数以及在何处使用它们的范式可能非常具有挑战性。但我想我已经提出了一种标准方法，可以使这项工作动态进行。

而手动映射这将很容易。

我可以重新路由 GET https://api.example.com/companies/1/users/到用户 Controller 而不是公司 Controller ，绕过它，只需将参数“1”设置为 WHERE 子句的公司 ID。

优势 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 列表。或者它可能只是动态路由器类的私有(private)属性。

好处 3:当 HTTP 方法不完全符合要求时

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

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

url => "https://api.example.com/tenant/"

Controller => "users"

Action => "login"

Params => "api_key, api_secret"

但是，我再一次看到了一个合理的选择。我可以创建另一个 Controller ，称为登录或租户，它实例化我的用户 Controller ，并运行登录功能。所以消费者可以只是 POST https://api.example.com/tenant/ ，有凭据，并责备。验证。

虽然，为了让这个替代方案工作，我必须物理创建另一个 Controller ，当使用 URL 映射器时，我不需要。但是这种关注点、功能和资源的分离也很好。但是，也许这是主要的权衡，您是宁愿只定义 URL 路由，还是必须为遇到的每个细微差别创建新类？

我没有看到或理解什么？我是否在这里缺少一个核心概念而只是无知？拥有典型的 URL 映射和路由类和功能是否有更多好处，我只是不知道，或者我几乎已经知道了？

Answer 1

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

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

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

真的不能低估，不要为了添加一个本质上不遵循相同规则的端点而对 Controller 和模型的实际结构进行黑客攻击，添加，删除，更改事物的唯一目的要安全得多其他 Controller 方法(API 端点)。

另一个非常重要的事情是，您的 API 端点实际上比我们通常意识到的更具可塑性。我的意思是，您可以在星期一处理端点的结构，然后在星期五，您从上面收到此任务，说您需要将所有这些 API 调用更改为某种其他结构，那就是美好的。但是如果你有一个大型应用程序，当你使用的框架对类命名、文件命名、物理规则有严格的规则时，这需要非常非常大量的文件重命名、类重命名、链接和各种非常易破坏的代码文件路径结构之类的……想象一下，更改一个类名以使其与新结构一起工作，现在您必须查找实例化旧类的每一行代码，并对其进行更改。此外，在这种情况下，可以说问题在于您的代码与 API 的 url 结构紧密耦合，如果您的 url 需要更改，这不是很容易维护。

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