架构:API 作为网站的核心 &移动应用 [英] Architecture: API as core for a website & mobile-app

问题描述

我对完整的架构想法有不同的疑问.我希望有丰富经验的人可以帮助我，因为我几乎陷入了所有的可能性.

I have different questions about a full architecture idea. I hope someone with great experience could help me out because I am pretty much getting stuck in all possibilities.

我打算重写一个社区网站.我们的客户希望在未来使用原生移动应用程序.所以我需要考虑到这一点.因此，我决定创建一个基于 PHP 框架 Kohana 的 100% REST API 架构.我选择 Kohana 是因为这可以很容易地将内部 API 扩展到其他服务器，而无需付出太多额外的努力.(Kohana 威胁内部 url 请求而不是 HTTP，因此一开始没有太多开销，并且可以通过一些小的代码更改扩展到 HTTP).

I'm planning to rewrite a community website. Our customer wants to make use of native mobile apps in the future. So I will need to take this into account. Because of this I have decided to create a 100% REST API architecture based on the PHP framework Kohana. I have choosen Kohana because this makes scaling the internal API to a other server very easily without much extra effort. (Kohana threats internal url requests not as HTTP so there isn't much overhead in the beginning and can scale to HTTP with some minor code changes).

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

At first the API will be private, but later on we might make it public to let more services connect to us easily.

基本的REST结构如下:

De basic REST structure is as follow:

1. /cats
2. /cats/1
3. /cats/1/custom

例如，'custom' 可以是 'childs'.

'custom' could be 'childs' for instance.

同样适用于:

1. /ads
2. /出价
3. /用户
4. /横幅
5. 等等.

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

These are perfect entities for the API because the mobile app will definitely use all this functionality.

因此我们可以得出结论，网站的核心是 REST.所以基本上我想让网站成为 API 的客户端，就像未来的原生应用程序一样.这样维护似乎容易多了.

So we can conclude the core of the website is REST. So basically I want to make the website a client of the API just like the native app in the future. This way maintenance seems much easier.

但让我担心的是，事实上还有更多(管理上传的文件、发票、发票自动邮件、广告自动邮件等).上传文件需要通过网站到API.这是普遍做法吗?如果我不这样做，网站会做上传逻辑，这使得网站不再是客户端，而是应用程序本身.因此，移动应用程序甚至无法上传，API 和网站都需要知道上传文件夹(重复逻辑).

What worries me though is the fact that there is much more than this (managing uploaded files, invoicing, automails for invoicing, automails for ads and so on). Uploading files needs to go through the website to the API. Is this common practice? If I do not do this, the website would do upload logic, which makes the site no client anymore and the app itself. Hence the mobile app can't even upload and both API and website need to know the upload folder (duplicate logic).

我想创建以下模块:

1. 社区 API
2. 社区网站

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

Api seems to be the core then. But.... what about cronjobs etc? Actually they should not be part of the website, as this is just a 'client'. I feel they should interact directly with the model or API. So basically the API gets more like a gateway to the core and thought I need this:

1. 社区核心
   • 模型
   • 定时任务
   • 自动邮寄(cronjobs 的一部分)
     • 发票等

• 通过 HTTP 与核心模型交互

• 网站
• 管理员

核心 cronjob 是 REST 结构的一个例外.它们是唯一一种无需通过 api 即可更改数据的方法.至少这是我的想法，因为它们属于核心，而 API 位于核心之上.

The core cronjobs are a exception to the REST structure. They are the only one that can change data without going through the api. At least that was my idea because they belong in the core and API is on top of the core.

但从设计上看，这似乎是错误的.操作应该只通过API！

But by design that seems just wrong. Manipulating should only go through the API!

替代方案:

1. 社区核心
   • 模型

• 通过 HTTP 与核心模型交互

• 定时任务
• 自动邮寄(cronjobs 的一部分)
  • 发票等
  • 网站
  • 管理员

  这在我看来设计得更好.
  _{(来源:mauserrifle.nl)}

  This look better by design to me.
  _{(source: mauserrifle.nl)}

  主要问题

  1)

  cronjobs 应该通过 API 还是 Core 模型进行操作?

  Should cronjobs manipulate through the API or Core models?

  2)

  我的发票 cronjob 需要一个模板，当然，它与主网站的风格非常相似.但是如果我的 cronjob 是业务或核心的一部分，它就不会知道我的主网站.解决这个问题有什么意义?

  My invoice cronjob needs a template pretty much the style of main website of course. But if my cronjob is part of business or core it won't have knowledge of my main website. What makes sense to solve this?

  3)

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

  My website will be using mustache as a template engine. (both php and javascript can parse these templates). I thought using the api directly for ajax calls but then realized:

  该站点从 api 获取数据，将时间戳格式化为模板的日期 (Y-m-d)，然后进行渲染.如果我让javascript直接调用api，javascript也必须有逻辑(格式化).这是重复代码！感觉唯一的解决方案是调用 ajax 网站(调用 api 和格式)并返回格式化的 json.我说得对吗?

  The site gets data from api, formats timestamps to dates (Y-m-d) for the template and then renders. If I let javascript call the api directly, javascript must have logic too (formatting). This is duplicate code! Feels like the only solution is calling the website for ajax (which calls the api and formats) and returns the formatted json. Am I right?

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

  But.... simple calls like deleting a ad can go through the api directly (e.g. DELETE: /ads/1

  我接到了各种各样的电话......

  I get a mix of calls....

  对此有更好的解决方案吗?

  Any better solution for this?

  4)

  总体:我的架构是否过于复杂?我应该考虑哪些替代方案?

  Overall: Is my architecture too complex? Any alternatives I should consider?

  我很想听听您的反馈！

  推荐答案

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

  Once I've heard that a good way to develop a web application is to develop an API-Centric Web Application. The thing is, to me, if you couple the main service to the public API, building an API-Centric application, you lose the whole point of developing a public API at all.

  这篇关于架构:API 作为网站的核心 &移动应用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！