我打算重写一个社区网站.我们的客户希望将来能够使用原生移动应用程序.所以我需要考虑到这一点.因此,我决定基于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与核心模型进行交互
>社区业务
>发票等
>社区网站
>网站
>管理员
对我来说这看起来更好看.
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)
总体而言：我的架构太复杂了吗？我应该考虑任何替代方案？
我很想听听你的反馈！
