具有公共 RESTful API + 本地访问 API 的应用程序架构

Question

我正在计划一个小型 Web 应用程序项目，该项目将由一个网站（使用 PHP）和未来的移动应用程序组成。我想实现一个 RESTful API（使用 PHP）来与移动应用程序通信。但是由于 API 和网站都将使用 PHP 编写并托管在同一台服务器上，因此从网站向公共 API 进行 HTTP 调用似乎有点奇怪（或者不是）？

无论如何，我正在考虑在 API 和业务逻辑之间放置一个层，基本上只是由一个对象组成，该对象公开与公共 RESTful API 相同的 API，但作为可以直接从网站访问的 PHP 对象。

1. 这是个好主意还是坏主意？为什么？
2. 这是众所周知的模式吗？如果有，它叫什么？

我发现一些网站提出了类似的结构并将其称为“API 网关对象”，但我不确定这是否是一个真正众所周知的模式，或者只是他们想出的东西。

这是我的想法的草图：

Answer 1

好问题（答案）...不确定它是否适合本网站。我使用的正是这种模式，在与其他架构方法/框架进行了艰苦的战斗后，我最终推出了这种模式，即我不知道它的名字。

一些优点：

• 事实证明它对测试也非常有用，爬上抽象阶梯可以很容易地构建和锻炼你最喜欢的测试玩具。
• 您的移动数据架构可以是网关对象模型的直接同构。
• 它很好地解耦了直接的 php 访问，并且它仍然允许您在重要的时候保留一些东西：身份验证、日志记录、数据库访问的可追溯性。
• 它为您的设计提供了未来的证明：虽然目前看起来很傻，但您可能会发现最终需要从不同的实例提供 www 和移动演示文稿。如果你做对了，迁移你的 php 演示文稿以使用 RESTful API 将是一件小事。

一个例子：假设我有一个Message 对象，这个对象将有许多“普通”类：

• 消息：plain-old-php-object，没有副作用，没有持久性
• MessageDAO ：Message 的持久性管理器。基本的 CRUD，没有业务逻辑，只有基本的 CRUD
• MessageWF：业务逻辑提供的工作流
• IBMessageSpec：消息规范
• OBMessage : 我希望发送给调用者的消息的表示

我使用 DI 容器在上述每个上下文中注入细节。

在我的 Mobile 中，我有 OBMessageSpec，它本质上是一个 IBMessageSpec，而 IBMessage 映射了服务器的 OBMessage。该代码几乎可以重用于多种实例类型和应用程序。

Answer 2

没关系的想法。您可以通过一些API Gateway Object 为内部PHP 使用提供API 并公开RESTful API，它使用相同的API Gateway Object。它可能被命名为Adapter，因为它使您的 php API 适应外部服务通过 HTTP 使用。

但是为什么你需要一些已知的模式来使用它呢？它完全符合您的需求，这种架构允许您保持模块一致并避免逻辑重复。

您可以在 PHP 端使用 RESTful，它会更慢，但更灵活 - 也许将来您需要用其他语言重写后端 - 您不需要更改前端！

所以，由你决定，什么更适合你，而不是模式。