我对完整的架构理念有不同的问题。我希望有丰富经验的人可以帮助我，因为我几乎陷入了所有可能性之中。
我正计划重写一个社区网站。我们的客户希望将来使用本机移动应用程序。所以我需要考虑到这一点。因此，我决定创建一个基于 PHP 框架 Kohana 的 100% REST API 架构。我选择 Kohana 是因为这使得将内部 API 扩展到其他服务器非常容易，而无需太多额外的工作。 （Kohana 威胁内部 url 请求而不是 HTTP，因此一开始没有太多开销，并且可以通过一些小的代码更改扩展到 HTTP）。
起初，API 将是私有的，但稍后我们可能会将其公开，以便让更多服务轻松连接到我们。
基本的REST结构如下：
例如，“定制”可以是“儿童”。
同样适用于：
这些是 API 的完美实体，因为移动应用程序肯定会使用所有这些功能。
所以我们可以得出网站的核心是REST。所以基本上我想让网站成为 API 的客户端，就像未来的本机应用程序一样。这样维护起来就显得容易多了。
但令我担心的是，事实远不止这些（管理上传的文件、发票、发票自动邮件、广告自动邮件等等）。上传文件需要通过网站API。这是常见做法吗？如果我不这样做，网站将执行上传逻辑，这使得网站和应用程序本身不再有客户端。因此，移动应用程序甚至无法上传，API 和网站都需要知道上传文件夹（重复逻辑）。
我想创建以下模块：
看来Api才是核心。但是.... cronjobs 等呢？实际上它们不应该成为网站的一部分，因为这只是一个“客户端”。我觉得他们应该直接与模型或 API 交互。所以基本上 API 更像是通往核心的网关，我认为我需要这个：
核心 cronjobs 是 REST 结构的一个例外。它们是唯一一种无需通过 api 即可更改数据的工具。至少这是我的想法，因为它们属于核心，而 API 位于核心之上。
但从设计上来说，这似乎是错误的。操作只能通过API！
选择：
This look better by design to me.
(source: mauserrifle.nl http://mauserrifle.nl/mindmap.jpg)
主要问题
1)
cronjobs 应该通过 API 还是核心模型进行操作？
2)
当然，我的发票 cronjob 需要一个几乎与主网站风格相同的模板。但是，如果我的 cronjob 是业务或核心的一部分，它就不会了解我的主网站。解决这个问题有什么意义？
3)
我的网站将使用 Mustache 作为模板引擎。 （php和javascript都可以解析这些模板）。我本以为直接使用 api 进行 ajax 调用，但后来意识到：
该站点从 api 获取数据，将时间戳格式化为模板的日期 (Y-m-d)，然后进行渲染。如果我让javascript直接调用api，javascript也必须有逻辑（格式化）。这是重复的代码！感觉唯一的解决方案是调用网站的ajax（调用api和格式）并返回格式化的json。我对吗？
但是...像删除广告这样的简单调用可以直接通过 api（例如 DELETE: /ads/1
我接到各种各样的电话......
对此有更好的解决方案吗？
4)
总体而言：我的架构是否太复杂？我应该考虑什么替代方案？
我很想听听您的反馈！
有一次我听说开发 Web 应用程序的一个好方法是开发一个以 API 为中心的 Web 应用程序 http://net.tutsplus.com/tutorials/php/creating-an-api-centric-web-application/。对我来说，问题是，如果您将主要服务与公共 API 结合起来，构建以 API 为中心的应用程序，那么您就完全失去了开发公共 API 的全部意义。
