即使是网站本身也使用网站的API？

Question

这个问题现在已经有一段时间了。

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

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

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

经典GUI：

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

使用API​​的GUI：

1. HTTP请求：由浏览器发送
2. PHP“发布”控制器：读取用户输入
3. HTTP API请求：由PHP Controller发送到站点的API URL
4. PHP“api”控制器：读取API请求
5. PHP模型：从数据库中获取帖子
6. PHP“api”控制器：填充“api”视图
7. PHP“api”查看：render（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网址

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

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

8. Javascript：改变DOM

“额外”调用需要时间，但RESTful架构努力通过缓存（通常根本不会导致网络活动）优化用户感知的性能，就像分块一样。有关更多分析，请参阅a previous answer of mine。