WordPress 6.1 对 REST API 进行了许多关键改进，以提高性能。这些改进减少了在每个 REST API 请求上运行的数据库查询的数量。
避免不必要地准备项目链接
在 WordPress 6.1 之前，prepare_links所有控制器都会调用 REST API 中的方法。如果将_fields参数传递给 REST API 请求，则可能意味着未请求链接字段并且永远不会在响应中返回。这是一种浪费，因为prepare_links它可能包含数据库调用或其他即使从未返回响应也会运行的复杂逻辑。
在 6.1中，prepare_links仅在响应中请求时调用，当在字段中请求链接或_embedded传递参数时。作为这项工作的一部分，分类和文章类型控制器现已更新，以实现上述prepare_links方法，使它们与其他 REST API 控制器保持一致。
以下是在自定义 REST API 控制器中实现此更改的代码示例。
更改之前
$response = rest_ensure_response( $data );
$links = $this->prepare_links( $post );
$response->add_links( $links );
return $response;更改之后
$response = rest_ensure_response( $data );
if ( rest_is_field_included( '_links', $fields ) || rest_is_field_included( '_embedded', $fields ) ) {
$links = $this->prepare_links( $post );
$response->add_links( $links );
}
return $response;此逻辑仅在_links或_embedded被请求时有条件地调用 prepare_links 。
有关更多信息，请参阅Trac 工单：#52992、#56019、#56020
Posts 控制器的改进
在针对 REST API 请求的响应运行分析工具时，发现 post 控制器会向每个 post 请求大量链接数据。例如，在 REST API 响应中返回文章时，所有链接的数据，如作者（用户）、特色图像和父帖子都被请求。由于这些链接的项目没有在缓存中准备好，这可能意味着对于 REST API 响应中的每个帖子，将有 3 个单独的数据库查询：一个用于用户，一个用于特色图像，另一个用于父帖子。
在 WordPress 6.1 中，所有缓存都在单个数据库查询中启动，并且有新的辅助函数可以实现这一点：
update_post_author_caches：在单个查询中获取一组帖子并准备用户缓存。
update_post_parent_caches：在单个查询中获取一组帖子和父帖子。
update_menu_item_cache：在单个查询获取一系列帖子并将帖子/术语链接到菜单项。
现有的update_post_thumbnail_cache函数用于准备特色图像缓存。这些功能也正在推广到内核的其他部分，这些部分可以从在一个地方启动缓存中受益。
有关更多信息，请参阅 Trac 工单：#55592、#55593、#55620
对其他控制器的改进
评论和用户控制器也得到了改进：用户控制器现在在单个查询中启动用户元，评论控制器现在在单个查询中启动链接的帖子缓存。对搜索后控制器进行了改进，以提高数据库性能以及媒体控制器。
有关更多信息，请参阅 Trac 工单：#55674、#56272、#55677、#55716
