自引入 WordPress REST API 以来，许多插件开发人员已开始将其插件转换为使用 REST API 而不是较旧的 AJAX API（admin-ajax.php）。除了 REST API 只是一种较新的技术外，有传言说 REST API 也比旧的端点更快，更可靠，原因是在典型的 REST 请求期间没有加载太多的 WordPress。
在本文中，我们将研究典型的REST请求以及提出的类似请求admin-ajax.php以了解它们之间的比较情况。
admin-ajax.php请求的寿命
让我们首先分解一下当我们向发出典型的 AJA X请求时会发生什么 admin-ajax.php 。当您的浏览器对该文件发出请求时，它会加载其他一些核心 WordPres s文件，以便能够在加载了核心功能的情况下满足请求：
/wp-load.php /wp-config.php /wp-settings.php //它会加载大多数核心文件，所有活动的插件和主题以及REST API /wp-admin/admin.php /wp-admin/includes/ajax-actions.php
加载这些文件后，WordPress 将调用该 admin_init 挂钩，几个核心功能都将挂钩。在 WordPress 4.5.3 的此钩子上调用了以下核心功能：
register_admin_color_schemes send_frame_options_header _wp_check_for_scheduled_split_terms _wp_admin_bar_init _maybe_update_core _maybe_update_plugins _maybe_update_themes
调用完这些函数后，WordPress 最终将调用 $_GET['action'] 或 $_POST['action'] 变量中提供的 AJAX 操作。
REST API请求的生命周期
与 admin-ajax.php 请求相比，典型的REST请求看起来略有不同。由于 REST 端点是由 WordPress 重写 API 处理的，因此请求将传递到 /index.php，然后正常加载其余 WordPress。
/index.php /wp-blog-header.php /wp-load.php /wp-config.php /wp-settings.php //它会加载大多数核心文件，所有活动的插件和主题以及REST API
与发送过来的请求不同 admin-ajax.php，REST API 不会通过加载 WordPress 管理部分 /wp-admin/admin.php，也不会触发 admin_init 动作挂钩。基于此，任何不依赖于管理员特定功能（但使用admin-ajax.php）的插件或主题都可能会通过切换到REST API来获得轻微的性能提升。
基准测试
既然我们已经看到了幕后发生的事情，那么让我们建立一个可以轻松进行基准测试的场景。为此，我们将创建一个可以在 admin-ajax.php 或 REST API上 运行的简单函数：
function benchmark_request() {
$result = array( 'time' => time() );
echo json_encode( $result );
exit;
}
add_action( 'wp_ajax_benchmark_request', 'benchmark_request' );
add_action( 'rest_api_init', function() {
register_rest_route( 'benchmark/v1', '/benchmark/', array(
'methods' => 'POST',
'callback' => 'benchmark_request'
) );
} );
上面的函数只是返回 JSON 中的时间-这只会有助于使您更容易看到请求没有被缓存。
为了执行实际的基准测试，我们将使用 ApacheBench ，这是一个命令行基准测试工具，它使您可以一次触发多个请求以了解服务器的性能。
让我们 admin-ajax.php 先测试版本。
ab -n 100 -c 1 -p ~/Desktop/post.data -g ~/Desktop/ajax.tsv -T application/x-www-form-urlencoded http://localhost/rest-api/wp-admin/admin-ajax.php
上面的命令将 100 个 POST 请求发送到该 /wp-admin/admin-ajax.php 文件并记录响应时间。post.data 引用的文件只是一个文本文件，其中包含要与请求一起发送的 URL 编码的 $ _POST 值（在本例中为 action=benchmark_request ）。
在 100 个请求下，在 MAMP 和 PHP 7 上全新安装 WordPress 且未激活其他插件的情况下，平均响应时间为 253ms。这为基于 REST API 的相同测试提供了良好的基准：
ab -n 100 -c 1 -p ~/Desktop/post.data -g ~/Desktop/rest.tsv -T application/x-www-form-urlencoded http://loc
毫不奇怪，在此比较中，REST API 的速度稍快，在 100 个请求中的平均响应时间为 217ms。显然，这并不是一个很大的差异，REST API 仅比传统的 AJAX API 快 15％，但是在许多请求中，这种微小的差异肯定会加起来，尤其是当添加了更多插件时。
让我们运行相同的基准测试，但激活一些插件。对于这些测试，我激活了一些常见的插件，您可能会在典型的网站上找到它们：
- ⭕ACF
- ⭕Akismet
- ⭕Black Studio TinyMCE小工具
- ⭕WP迁移数据库
- ⭕WP超级缓存
- ⭕Yoast SEO
尽管总体响应时间有所增加，但 admin-ajax.php 和 REST API 之间的性能差距仍然大致相同。随着额外的插件加载，REST API，将约 16％ 的速度，并有一个平均响应时间 490ms 相比567ms 以上 admin-ajax.php：
具有大量插件的网站可以通过 REST API 看到更大的性能提升，但这完全取决于正在运行哪些插件以及如何对其进行编码。
因此，您应该使用WordPress REST API吗？
从性能的角度来看，显然有一点优势。添加自定义 API 端点非常简单，并且由于不必加载太多 WordPress 核心（包括管理区域和常用 admin_init 钩子），因此它 admin-ajax.php 在大多数情况下可能会比使用更快。
在可靠性方面，REST API 仍取决于活动插件或主题的质量和完整性。编码不良的插件仍可能轻易干扰 REST 请求，尤其是将来有更多插件采用 REST API 时。但是，由于使用 REST API 的插件较少，因此目前应该更可靠。
总体而言，至少考虑使用 REST API 绝对是一个好主意。添加自定义 API 端点非常简单，并且切换现有代码也不需要很多。
