关于完整的体系结构构想,我有不同的疑问。我希望有丰富经验的人可以帮助我,因为我几乎陷入了所有可能性。
我打算重写一个社区网站。我们的客户希望将来使用 native 移动应用程序。因此,我需要考虑到这一点。因此,我决定基于PHP框架Kohana创建100%REST API架构。我之所以选择Kohana,是因为这可以轻松地将内部API扩展到其他服务器,而无需付出额外的努力。 (Kohana不以HTTP威胁内部url请求,因此一开始没有太多开销,并且可以通过一些小的代码更改就可以扩展到HTTP)。
最初,API将是私有(private)的,但后来我们可能将其公开,以使更多服务轻松地连接到我们。
基本的REST结构如下:
例如,“习惯”可以是“ child ”。
同样适用于:
这些是API的完美实体,因为移动应用程序肯定会使用所有这些功能。
因此,我们可以得出结论,该网站的核心是REST。因此,基本上,我希望像将来的 native 应用程序一样,使网站成为API的客户端。这样,维护似乎容易得多。
尽管令我感到担忧的是,事实还远远不止于此(管理上载的文件,发票,用于发票的自动邮件,用于广告的自动邮件等等)。上传文件需要通过网站到达API。这是惯例吗?如果我不这样做,则该网站将执行上传逻辑,这将使该站点不再是客户端,也不再是该应用程序本身。因此,移动应用甚至无法上传,API和网站都需要知道上传文件夹(重复逻辑)。
我想到了创建以下模块:
那时,Api似乎是核心。但是.... cronjobs等呢?实际上,它们不应该是网站的一部分,因为这只是“客户”。我觉得他们应该直接与模型或API进行交互。因此,基本上,API变得更像是通往核心的网关,并认为我需要这样做:
核心cronjobs是REST结构的一个异常(exception)。它们是唯一无需通过api即可更改数据的控件。至少那是我的想法,因为它们属于核心,而API在核心之上。
但是从设计来看,这似乎是错误的。只能通过API进行操作!
选择:
这对我来说看起来更好。
(来源: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)
总的来说:我的架构太复杂了吗?我应该考虑其他选择吗?
我希望听到您的反馈!
最佳答案
一旦我听说开发Web应用程序的好方法就是开发API-Centric Web Application。对我而言,如果将主服务耦合到公共(public)API,构建以API为中心的应用程序,那么您根本就失去了开发公共(public)API的全部目的。
关于php - 架构:API作为网站和移动应用程序的核心,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9453359/