我对完整架构的想法有不同的疑问。我希望有经验的人可以帮助我，因为我几乎陷入了各种可能性。
我打算重写一个社区网站。我们的客户希望将来能够使用原生移动应用程序。所以我需要考虑到这一点。因此，我决定基于PHP框架Kohana创建一个100％REST API架构。我选择了Kohana，因为这样可以非常轻松地将内部API扩展到其他服务器而无需额外的努力。 （Kohana威胁内部URL请求不是HTTP，因此开头没有太多开销，可以通过一些小的代码更改扩展到HTTP。）
首先，API将是私有的，但稍后我们可能会公开让更多服务轻松连接到我们。
De basic REST结构如下：
同样适用于：
这些是API的完美实体，因为移动应用肯定会使用所有这些功能。
因此我们可以得出结论，网站的核心是REST。所以基本上我想让网站成为API的客户端，就像将来的本机应用程序一样。这样维护似乎更容易。
令我担心的是，除此之外还有更多（管理上传文件，发票，发票自动化，广告自动化等）。上传文件需要通过网站访问API。这是常见做法吗？如果我不这样做，网站将上传逻辑，这使网站不再是客户端和应用程序本身。因此，移动应用程序甚至无法上传，API和网站都需要知道上传文件夹（重复逻辑）。
我想到了创建以下模块：
Api似乎是核心。但是......那些cronjobs等呢？实际上他们不应该成为网站的一部分，因为这只是一个“客户”。我觉得他们应该直接与模型或API进行交互。所以基本上API更像是通往核心的网关，我认为我需要这个：
核心cronjobs是REST结构的一个例外。他们是唯一一个可以在不通过api的情况下更改数据的人。至少这是我的想法，因为它们属于核心，而API则位于核心之上。
但设计似乎错了。操作应该只通过API！
替代：
这对我来说看起来更好看。 Mindmap illustration http://mauserrifle.nl/mindmap.jpg
主要问题
1）
cronjobs应该通过API还是Core模型进行操作？
2）
我的发票cronjob当然需要一个主要网站风格的模板。但如果我的cronjob是业务或核心的一部分，它将无法了解我的主要网站。解决这个问题有什么意义呢？
3）
我的网站将使用小胡子作为模板引擎。 （php和javascript都可以解析这些模板）。我认为直接使用api进行ajax调用，但后来意识到：
该网站从api获取数据，将时间戳格式化为模板的日期（Y-m-d），然后呈现。如果我让javascript直接调用api，javascript也必须有逻辑（格式化）。这是重复的代码！感觉像唯一的解决方案是调用网站的ajax（调用api和格式）并返回格式化的json。我是对的吗？
但....删除广告等简单调用可直接通过api（例如DELETE：/ ads / 1
我收到各种电话......
对此更好的解决方案吗？
4）
总体而言：我的架构太复杂了吗？我应该考虑的其他选择吗？
我很想听听您的反馈意见！
答案 0 :(得分：3)
有一次我听说开发Web应用程序的好方法是开发API-Centric Web Application。对我而言，如果您将主要服务与公共API相结合，构建以API为中心的应用程序，那么您将完全失去开发公共API的全部意义。
答案 1 :(得分：2)
这对我来说似乎不合逻辑。
是的，API和网站以及接下来会发生的事情是单独的事情，网站应该是API本身的客户端，但是因为它会简化内容，我相信你应该重新使用域类来构建和建立您的网站逻辑。这样您就可以使用所有相同的代码库并轻松处理所有问题，包括广告，发票和文件上传。
对于公共API，它应该在一个单独的框中，如果可能的话，重新使用相同的域类但使用不同的身份验证方法，以便不管出现什么问题，它都不会影响主服务。
您的cron-jobs应仅用于通过API本身触发呼叫，并且这些呼叫应在主应用程序（通过API的网站）上进行
如果您构建自己的网站而不重复自己，例如，使用与基础相同的代码并围绕它包装网络应用程序，则不会在q＃2中出现问题。
同样的问题适用于第3个问题。如果你围绕API包装网站，网站可以使用api本身而不是一个单独的实体。
您的架构似乎很复杂但如果您执行这些操作，则会很简单。 ; - ）
祝你好运！答案 2 :(得分：0)
REST只是发起请求的一种方式。处理请求的核心代码不应与REST接口紧密耦合，也不应与HTTP紧密耦合。我建议将REST API设计为包含文件或类似内容的简单映射器。然后，您的cron可以绕过整个REST API并直接包含该文件。将请求接口与执行实际处理的代码分开。
