php – API作为网站和移动应用的核心

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

我打算重写一个社区网站.我们的客户希望将来能够使用原生移动应用程序.所以我需要考虑到这一点.因此,我决定基于PHP框架Kohana创建一个100％REST API架构.我选择了Kohana,因为这样可以非常轻松地将内部API扩展到其他服务器而无需额外的努力. (Kohana威胁内部URL请求不是HTTP,因此开头没有太多开销,可以通过一些次要的代码更改扩展到HTTP).

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

De basic REST结构如下：

> /猫
> / cats / 1
> / cats / 1 / custom

例如,’custom’可能是’孩子’.

同样适用于：

> / ads
> /出价
> /用户
> /横幅
>等..

这些是API的完美实体,因为移动应用程序肯定会使用所有这些功能.

所以我们可以得出结论,网站的核心是REST.所以基本上我想让网站成为API的客户端,就像将来的本机应用程序一样.这样维护似乎更容易.

令我担心的是,除此之外还有更多(管理上传文件,发票,发票自动化,广告自动化等).上传文件需要通过网站访问API.这是常见做法吗？如果我不这样做,网站将上传逻辑,这使得网站不再是客户端和应用程序本身.因此,移动应用程序甚至无法上传,API和网站都需要知道上传文件夹(重复逻辑).

我想到了创建以下模块：

> community-api
>社区网站

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

>社区核心

>模特
> Cronjobs
>自动邮件(cronjobs的一部分)

>发票等

> community-api

>通过HTTP与核心模型进行交互

>社区网站

>网站
>管理员

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

但设计似乎是错误的.操作应该只通过API！

替代方案：

>社区核心

>模特

> community-api

>通过HTTP与核心模型进行交互

>社区业务

> Cronjobs
>自动邮件(cronjobs的一部分)

>发票等

>社区网站

>网站
>管理员

对我来说这看起来更好看.
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)

总体而言：我的架构太复杂了吗？我应该考虑任何替代方案？

我很想听听你的反馈！