6

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

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

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

基本的 REST 结构如下：

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

例如，“custom”可以是“childs”。

同样适用于：

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

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

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

但让我担心的是，还有更多的事情（管理上传的文件、发票、发票自动邮件、广告自动邮件等等）。上传文件需要通过网站到API。这是常见的做法吗？如果我不这样做，网站会执行上传逻辑，这会使网站不再是客户端，应用程序本身也不再存在。因此移动应用程序甚至无法上传，API 和网站都需要知道上传文件夹（重复逻辑）。

我想创建以下模块：

  1. 社区 API
  2. 社区网站

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

  1. 社区核心
    • 楷模
    • 定时任务
    • 自动邮件（cronjobs 的一部分）
      • 发票等
  2. 社区 API
    • 通过 HTTP 与核心中的模型交互
  3. 社区网站
    • 网站
    • 行政

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

但按照设计，这似乎是错误的。操作应该只通过 API！

选择：

  1. 社区核心
    • 楷模
  2. 社区 API
    • 通过 HTTP 与核心中的模型交互
  3. 社区业务
    • 定时任务
    • 自动邮件（cronjobs 的一部分）
      • 发票等
  4. 社区网站
    • 网站
    • 行政

在我看来，这在设计上看起来更好。 （来源：mauserrifle.nl）思维导图插图

主要问题

1)

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

2)

当然，我的发票 cronjob 需要一个与主网站样式差不多的模板。但是，如果我的 cronjob 是业务或核心的一部分，它就不会知道我的主要网站。解决这个问题有什么意义？

3)

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

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

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

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

有什么更好的解决方案吗？

4)

总体：我的架构是否过于复杂？我应该考虑的任何替代方案？

我很想听听您的反馈！

4

3 回答 3

3

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

于 2012-02-27T12:51:26.383 回答
2

这对我来说似乎不合逻辑。

是的，API 和网站以及接下来可能发生的事情是分开的，网站应该是 API 本身的客户端，但由于它会简化事情，我相信你应该重用域类来构建和基础你的网站逻辑。通过这种方式，您可以使用所有相同的代码库并轻松处理所有问题，包括广告、发票，当然还有文件上传。

对于公共 API，如果可能的话，它应该放在一个单独的盒子上，重新使用相同的域类但使用不同的身份验证方法，这样无论发生什么问题，它都不会影响主服务。

您的 cron-jobs 只能用于通过 API 本身触发调用，并且这些调用应该在主应用程序（通过 API 的网站）上进行

如果您在不重复自己的情况下构建您的网站，例如，使用与基础相同的代码并将网络应用程序包装在它周围，那么您将不会遇到 q#2 中出现的问题。

同样的事情也适用于第 3 个问题。如果您将网站包装在 API 周围，则网站可以使用 api 本身，而不是一个单独的实体。

你的架构看起来很复杂，但如果你做这些事情，它会很简单。;-)

祝你好运！

于 2012-02-26T21:33:08.690 回答
0

REST 只是发起请求的一种方式。处理请求的核心代码不应与 REST 接口或 HTTP 紧密耦合。我建议将您的 REST API 设计为包含文件或类似文件的简单映射器。然后，您的 cron 可以绕过整个 REST API 并直接包含该文件。将请求接口与执行实际处理的代码分开。

于 2012-02-26T23:27:46.833 回答