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

Question

关于完整的体系结构构想，我有不同的疑问。我希望有丰富经验的人可以帮助我，因为我几乎陷入了所有可能性。
我打算重写一个社区网站。我们的客户希望将来使用 native 移动应用程序。因此，我需要考虑到这一点。因此，我决定基于PHP框架Kohana创建100％REST API架构。我之所以选择Kohana，是因为这可以轻松地将内部API扩展到其他服务器，而无需付出额外的努力。 (Kohana不以HTTP威胁内部url请求，因此一开始没有太多开销，并且可以通过一些小的代码更改就可以扩展到HTTP)。
最初，API将是私有(private)的，但后来我们可能将其公开，以使更多服务轻松地连接到我们。
基本的REST结构如下:

/cat

/cats/1

/cats/1/自定义

例如，“习惯”可以是“ child ”。
同样适用于:

/ads

/出价

/用户

/横幅

等。

这些是API的完美实体，因为移动应用程序肯定会使用所有这些功能。
因此，我们可以得出结论，该网站的核心是REST。因此，基本上，我希望像将来的 native 应用程序一样，使网站成为API的客户端。这样，维护似乎容易得多。
尽管令我感到担忧的是，事实还远远不止于此(管理上载的文件，发票，用于发票的自动邮件，用于广告的自动邮件等等)。上传文件需要通过网站到达API。这是惯例吗？如果我不这样做，则该网站将执行上传逻辑，这将使该站点不再是客户端，也不再是该应用程序本身。因此，移动应用甚至无法上传，API和网站都需要知道上传文件夹(重复逻辑)。
我想到了创建以下模块:

community-api

社区网站

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

社区核心

模型

Cronjobs

自动邮件(cronjobs的一部分)

发票等

community-api

通过HTTP

与核心模型交互

社区网站

网站

管理员

核心cronjobs是REST结构的一个异常(exception)。它们是唯一无需通过api即可更改数据的控件。至少那是我的想法，因为它们属于核心，而API在核心之上。
但是从设计来看，这似乎是错误的。只能通过API进行操作!
选择:

社区核心

模型

community-api

通过HTTP

与核心模型交互

社区业务

Cronjobs

自动邮件(cronjobs的一部分)

发票等

社区网站

网站

管理员

这对我来说看起来更好。

(来源: mauserrifle.nl)
主要问题
1)
cronjobs应该通过API还是Core模型进行操纵？
2)
我的发票cronjob当然非常需要主要网站的样式的模板。但是，如果我的cronjob是业务或核心业务的一部分，它将不了解我的主要网站。解决这个问题有什么意义？
3)
我的网站将 mustache 用作模板引擎。 (php和javascript都可以解析这些模板)。我以为直接将API用于ajax调用，但后来意识到:
该网站从api获取数据，将时间戳格式设置为模板的日期(Y-m-d)，然后进行渲染。如果我让javascript直接调用api，则javascript也必须具有逻辑(格式)。这是重复的代码!感觉唯一的解决方案是调用ajax网站(调用api和format)并返回格式化的json。我对吗？
但是....简单的调用(例如删除广告)可以直接通过api(例如DELETE:/ads/1
我打来个电话...
有更好的解决方案吗？
4)
总的来说:我的架构太复杂了吗？我应该考虑其他选择吗？
我希望听到您的反馈!

Answer 1

一旦我听说开发Web应用程序的好方法就是开发API-Centric Web Application。对我而言，如果将主服务耦合到公共(public)API，构建以API为中心的应用程序，那么您根本就失去了开发公共(public)API的全部目的。