自引入WordPress REST API以來，許多插件開發(fā)人員已開始將其插件轉換為使用REST API而不是較舊的AJAX API（admin-ajax.php）。除了REST API只是一種較新的技術外，有傳言說REST API也比舊的端點更快，更可靠，原因是在典型的REST請求期間沒有加載太多的WordPress。
在本文中，我們將研究典型的REST請求以及提出的類似請求admin-ajax.php以了解它們之間的比較情況。
- 原文來源于：詳情
admin-ajax.php請求的壽命
讓我們首先分解一下當我們向發(fā)出典型的AJAX請求時會發(fā)生什么admin-ajax.php。當您的瀏覽器對該文件發(fā)出請求時，它會加載其他一些核心WordPress文件，以便能夠在加載了核心功能的情況下滿足請求：
/wp-load.php/wp-config.php/wp-settings.php?（它會加載大多數(shù)核心文件，所有活動的插件和主題以及REST API）/wp-admin/admin.php/wp-admin/includes/ajax-actions.php
加載這些文件后，WordPress將調用該admin_init掛鉤，幾個核心功能都將掛鉤。在WordPress 4.5.3的此鉤子上調用了以下核心功能：
register_admin_color_schemessend_frame_options_header_wp_check_for_scheduled_split_terms_wp_admin_bar_init_maybe_update_core_maybe_update_plugins_maybe_update_themes
調用完這些函數(shù)后，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?（它會加載大多數(shù)核心文件，所有活動的插件和主題以及REST API）
與發(fā)送過來的請求不同admin-ajax.php，REST API不會通過加載WordPress管理部分/wp-admin/admin.php，也不會觸發(fā)admin_init動作掛鉤?；诖?，任何不依賴于管理員特定功能（但使用admin-ajax.php）的插件或主題都可能會通過切換到REST API來獲得輕微的性能提升。
基準測試
既然我們已經看到了幕后發(fā)生的事情，那么讓我們建立一個可以輕松進行基準測試的場景。為此，我們將創(chuàng)建一個可以在admin-ajax.php或REST API上運行的簡單函數(shù)：
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'
) );
} );
上面的函數(shù)只是返回JSON中的時間-這只會有助于使您更容易看到請求沒有被緩存。
為了執(zhí)行實際的基準測試，我們將使用ApacheBench，這是一個命令行基準測試工具，它使您可以一次觸發(fā)多個請求以了解服務器的性能。
讓我們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請求發(fā)送到該/wp-admin/admin-ajax.php文件并記錄響應時間。post.data引用的文件只是一個文本文件，其中包含要與請求一起發(fā)送的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僅比傳統(tǒng)的AJAX API快15％，但是在許多請求中，這種微小的差異肯定會加起來，尤其是當添加了更多插件時。
讓我們運行相同的基準測試，但激活一些插件。對于這些測試，我激活了一些常見的插件，您可能會在典型的網站上找到它們：
- ACF
- Akismet
- Black Studio TinyMCE小工具
- WP遷移數(shù)據(jù)庫
- WP超級緩存
- Yoast SEO
盡管總體響應時間有所增加，但admin-ajax.php和REST API之間的性能差距仍然大致相同。隨著額外的插件加載，REST API，將約16％的速度，并有一個平均響應時間490ms相比567ms以上admin-ajax.php：
具有大量插件的網站可以通過REST API看到更大的性能提升，但這完全取決于正在運行哪些插件以及如何對其進行編碼。
因此，您應該使用WordPress REST API嗎？
從性能的角度來看，顯然有一點優(yōu)勢。添加自定義API端點非常簡單，并且由于不必加載太多WordPress核心（包括管理區(qū)域和常用admin_init鉤子），因此它admin-ajax.php在大多數(shù)情況下可能會比使用更快。
在可靠性方面，REST API仍取決于活動插件或主題的質量和完整性。編碼不良的插件仍可能輕易干擾REST請求，尤其是將來有更多插件采用REST API時。但是，由于使用REST API的插件較少，因此目前應該更可靠。
總體而言，至少考慮使用REST API絕對是一個好主意。添加自定義API端點非常簡單，并且切換現(xiàn)有代碼也不需要很多。