api - 甚至为网站本身使用网站的 API？

Question

这个问题在我脑海里已经有一段时间了。

假设我有一个 PHP 网站，它有一个 API(SOAP、REST 等)，并且这个 API 提供的内容几乎与页面中可用的内容相同(例如博客文章、评论、统计信息等)。

为了避免代码冗余/重复，我正在考虑甚至对站点本身使用 API，因为尽管大多数代码分解已经通过使用 MVC 模型完成，但如果站点必须提供 API，某些逻辑仍然是双重的.

访问者检索给定博客帖子的示例:

经典图形用户界面:

HTTP请求:由浏览器发送

PHP Controller :读取用户输入

PHP 模型:从数据库中获取帖子

PHP Controller :填充 View

PHP View :渲染 HTML

HTTP 响应:发送到浏览器

使用 API 的图形用户界面:

HTTP请求:由浏览器发送

PHP“帖子” Controller :读取用户输入

HTTP API 请求:由 PHP Controller 发送到站点的 API URL

PHP "api" Controller :读取 API 请求

PHP 模型:从数据库中获取帖子

PHP“api” Controller :填充“api” View

PHP“api” View :渲染(XML、JSON 等)

HTTP API 响应:发送到第 2 点的 PHP Controller 。

PHP Controller :填充 View

PHP View :渲染 HTML

HTTP 响应:发送到浏览器

我的意见是 GUI 应该 是一个消耗 API 的层(一个新层)，但我担心性能问题，因为在 PHP 网站中，API 调用通过一个需要时间的 HTTP 请求。

Answer 1

通常，您不希望服务器对其自身进行类似的“内部”调用。相反，让初始 HTML 包含驱动交互的 Javascript:

GUI 的 HTTP 请求:由浏览器发送

HTTP 响应:静态 HTML(大量缓存)

HTTP API 请求:通过 AJAX 发送到站点的 API URL

PHP "api" Controller :读取 API 请求

PHP 模型:从数据库中获取帖子

PHP“api” Controller :将“api” View 填充为 JSON

HTTP API 响应:发送到第 3 点的浏览器。

Javascript:更改 DOM

“额外”调用需要时间，但 RESTful 架构努力通过缓存(通常导致根本没有网络事件)与分 block 一样优化用户感知性能。见 a previous answer of mine进行更多分析。