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

Question

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

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

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

De基本REST结构如下:

1. /猫
2. /猫/ 1
3. /猫/ 1 /自定义

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

同样的:

1. /广告
2. /出价书
3. /用户
4. /横幅
5. 等等..

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

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

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

我想到了创建以下模块:

1. 社区API
2. 社区网站

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

1. 以社区为核心
   • 楷模
   • Cronjobs
   • 汽车邮件(cronjobs的一部分)
     • 发票等
2. 社区API
   • 通过HTTP与核心模型交互
3. 社区网站
   • 网站
   • 管理员

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

但设计似乎错了.操作应该只通过API!

替代方案:

1. 以社区为核心
   • 楷模
2. 社区API
   • 通过HTTP与核心模型交互
3. 社区业务
   • Cronjobs
   • 汽车邮件(cronjobs的一部分)
     • 发票等
4. 社区网站
   • 网站
   • 管理员

这对我来说设计看起来更好. 思维导图插图http://mauserrifle.nl/mindmap.jpg

主要问题

1)

cronjobs应该通过API或Core模型进行操作吗？

2)

我的发票cronjob当然需要一个主要网站风格的模板.但如果我的cronjob是业务或核心的一部分,它将无法了解我的主要网站.解决这个问题有什么意义？

3)

我的网站将使用小胡子作为模板引擎.(php和javascript都可以解析这些模板).我认为直接使用api进行ajax调用,但后来意识到:

该站点从api获取数据,将时间戳格式化为模板的日期(Ymd),然后呈现.如果我让javascript直接调用api,javascript也必须有逻辑(格式化).这是重复的代码!感觉像唯一的解决方案是调用网站的ajax(调用api和格式)并返回格式化的json.我对吗？

但是....删除广告等简单的调用可以直接通过api(例如DELETE:/ ads/1

我收到各种电话....

对此更好的解决方案？

4)

总体而言:我的架构太复杂了吗？我应该考虑哪些替代方案？

我很想听听你的反馈!

Answer 1

我曾经听说开发 Web 应用程序的一个好方法是开发一个以 API 为中心的 Web 应用程序。对我来说，问题是，如果您将主要服务与公共 API 结合起来，构建以 API 为中心的应用程序，那么您就完全失去了开发公共 API 的全部意义。