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

Question

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

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

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

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

经典图形用户界面：

1. HTTP 请求：由浏览器发送
2. PHP 控制器：读取用户输入
3. PHP模型：从数据库中获取帖子
4. PHP 控制器：填充视图
5. PHP 视图：呈现 HTML
6. HTTP 响应：发送到浏览器

使用 API 的图形用户界面：

1. HTTP 请求：由浏览器发送
2. PHP“帖子”控制器：读取用户输入
3. HTTP API 请求：由 PHP 控制器发送到站点的 API URL
4. PHP“api”控制器：读取 API 请求
5. PHP模型：从数据库中获取帖子
6. PHP“api”控制器：填充“api”视图
7. PHP“api”视图：渲染（XML、JSON 等）
8. HTTP API 响应：发送到第 2 点的 PHP 控制器。
9. PHP 控制器：填充视图
10. PHP 视图：呈现 HTML
11. HTTP 响应：发送到浏览器

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

Answer 1

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

1. GUI 的 HTTP 请求：由浏览器发送

2. HTTP 响应：静态 HTML（大量缓存）

3. HTTP API 请求：通过 AJAX 发送到站点的 API URL

4. PHP“api”控制器：读取 API 请求
5. PHP模型：从数据库中获取帖子
6. PHP“api”控制器：将“api”视图填充为 JSON

7. HTTP API 响应：发送到第 3 点的浏览器。

8. Javascript：改变 DOM

“额外”调用需要时间，但 RESTful 架构努力通过缓存（通常导致根本没有网络活动）与分块一样优化用户感知性能。有关更多分析，请参阅我以前的答案。