架构：API 作为网站和移动应用程序的核心

Question

我对完整的架构理念有不同的疑问。我希望有丰富经验的人可以帮助我，因为我几乎陷入了各种可能性。

我打算重写一个社区网站。我们的客户希望在未来使用原生移动应用程序。所以我需要考虑到这一点。正因为如此，我决定创建一个基于 PHP 框架 Kohana 的 100% REST API 架构。我之所以选择 Kohana，是因为这可以很容易地将内部 API 扩展到其他服务器，而无需付出太多额外的努力。 （Kohana 威胁内部 url 请求不像 HTTP，所以一开始没有太多开销，并且可以通过一些小的代码更改扩展到 HTTP）。

起初 API 是私有的，但稍后我们可能会将其公开以让更多服务轻松连接到我们。

基本的REST结构如下：

1. /猫
2. /cats/1
3. /cats/1/custom

例如，'custom' 可以是 'childs'。

同样适用：

1. /广告
2. /出价
3. /用户
4. /横幅
5. 等等..

这些是 API 的完美实体，因为移动应用肯定会使用所有这些功能。

因此我们可以得出结论，网站的核心是 REST。所以基本上我想让网站成为 API 的客户端，就像未来的原生应用程序一样。这样维护起来似乎容易多了。

但让我担心的是，还有更多的事情（管理上传的文件、开票、开票的自动邮件、广告的自动邮件等等）。上传文件需要通过网站到API。这是常见的做法吗？如果我不这样做，网站会执行上传逻辑，这会使网站不再是客户端，应用程序本身也不再存在。因此移动应用程序甚至无法上传，API 和网站都需要知道上传文件夹（重复逻辑）。

我想创建以下模块：

1. 社区-api
2. 社区网站

Api 似乎是当时的核心。但是.... cronjobs 等呢？实际上它们不应该是网站的一部分，因为这只是一个“客户”。我觉得他们应该直接与模型或 API 交互。所以基本上 API 更像是通往核心的网关，我认为我需要这个：

1. 社区核心
   • 型号
   • 定时任务
   • 自动邮件（cronjobs 的一部分）
     • 发票等
2. 社区-api
   • 通过 HTTP 与核心中的模型交互
3. 社区网站
   • 网站
   • 管理员

核心 cronjobs 是 REST 结构的一个例外。它们是唯一可以在不通过 api 的情况下更改数据的。至少这是我的想法，因为它们属于核心，而 API 位于核心之上。

但从设计上看，这似乎是错误的。操作只能通过 API！

替代方案：

1. 社区核心
   • 型号
2. 社区-api
   • 通过 HTTP 与核心中的模型交互
3. 社区业务
   • 定时任务
   • 自动邮件（cronjobs 的一部分）
     • 发票等
4. 社区网站
   • 网站
   • 管理员

在我看来，这在设计上看起来更好。
_{（来源：mauserrifle.nl）}

主要问题

1)

cronjobs 应该通过 API 或 Core 模型进行操作吗？

2)

我的发票 cronjob 当然需要一个与主网站样式差不多的模板。但是，如果我的 cronjob 是业务或核心的一部分，它就不会知道我的主要网站。解决这个问题有什么意义？

3)

我的网站将使用 mustache 作为模板引擎。 （php 和 javascript 都可以解析这些模板）。我以为直接使用 api 进行 ajax 调用，但后来意识到：

站点从 api 获取数据，将时间戳格式化为模板的日期 (Y-m-d)，然后呈现。如果我让javascript直接调用api，javascript也必须有逻辑（格式化）。这是重复的代码！感觉唯一的解决方案是调用 ajax 网站（调用 api 和格式）并返回格式化的 json。我说的对吗？

但是....像删除广告这样的简单调用可以直接通过api（例如DELETE：/ads/1

我接到各种各样的电话....

有什么更好的解决方案吗？

4)

总体而言：我的架构是否过于复杂？我应该考虑什么替代方案？

我很想听听您的反馈！

Answer 1

这对我来说似乎不合逻辑。

是的，API 和网站以及接下来可能发生的事情是分开的，网站应该是 API 本身的客户端，但由于它会大大简化事情，我相信你应该重用域类来建立和建立您的网站逻辑。通过这种方式，您可以使用所有相同的代码库并轻松处理所有问题，包括广告、发票，当然还有文件上传。

对于公共 API，如果可能的话，它应该放在一个单独的盒子上，重复使用相同的域类但使用不同的身份验证方法，这样无论发生什么问题，它都不会影响主服务。

您的 cron-jobs 应仅用于通过 API 本身触发调用，并且这些调用应在主应用程序（通过 API 的网站）上进行

如果您构建自己的网站而不重复自己，例如使用与基础相同的代码并将网络应用程序包装在其周围，那么您将不会遇到问题 2 中提出的问题。

同样的问题也适用于第 3 个问题。如果您将网站包装在 API 周围，则网站可以使用 API 本身，而不是一个单独的实体。

你的架构看起来很复杂，但如果你做这些事情，它就会很简单。 ;-)

祝你好运！

Answer 2

REST 只是发起请求的一种方式。处理请求的核心代码不应与 REST 接口或 HTTP 紧密耦合。我建议将您的 REST API 设计为包含文件或类似文件的简单映射器。然后，您的 cron 可以绕过整个 REST API 并直接包含该文件。将请求接口与执行实际处理的代码分开。

Answer 3

我听说开发 Web 应用程序的一个好方法是开发一个API-Centric Web Application。对我来说，如果你将主要服务与公共 API 结合起来，构建一个以 API 为中心的应用程序，那么你就完全失去了开发公共 API 的意义。