如何让 WordPress REST API 端点不带 wp-json 前缀？

2026-11-04数据小许

可以为 /api/log 添加一条内部重写规则，让 WordPress 将请求交给现有的 /api/log REST 路由处理。程序仍然请求 https://mywebsite/api/log，无需修改硬编码 URL，也无需跟随 HTTP 重定向。

以下方案假设 WordPress 的对外入口位于网站根路径，且 /wp-json/api/log 已经能够正确处理 POST 请求。

为什么可以绕过 wp-json

WordPress 的 REST API 重写规则会将 /wp-json/... 映射到 index.php?rest_route=/...。按照同样的方式，可以单独将 /api/log 映射到 index.php?rest_route=/api/log。WordPress 官方源码

这里的 rest_route 值不包含 wp-json。这条规则为现有端点增加一个访问入口，原来的 /wp-json/api/log 仍然可用。

添加精确匹配的重写规则

将下面的代码保存为 wp-content/plugins/api-log-alias/api-log-alias.php，然后在后台启用插件：

<?php
/**
 * Plugin Name: API Log Alias
 * Description: Adds /api/log as an alias for an existing REST route.
 */

add_action( 'init', function () {
    add_rewrite_rule(
        '^api/log/?$',
        'index.php?rest_route=/api/log',
        'top'
    );
} );

规则只匹配 /api/log 和 /api/log/。top 将规则放到较高优先级，减少被其他常规规则先匹配的机会。相关参数见 add_rewrite_rule() 文档。

启用插件后，进入 WordPress 后台的“设置 → 固定链接”，点击一次“保存更改”，刷新重写规则。添加或修改规则后都需要刷新，但不要在每次请求时调用 flush_rewrite_rules()，因为这个操作开销较大。flush_rewrite_rules() 文档

现有 REST 路由无需重复注册，POST 回调和权限检查仍会执行。内部重写在同一次请求中完成，客户端不必重新发送请求，原来的请求方法和请求体也会保留。

验证 POST 请求是否到达原端点

在测试环境中，使用端点允许的请求体和认证信息访问新地址。例如，若端点接受 JSON，可以从下面的命令开始：

curl -i 'https://mywebsite/api/log' \
  -H 'Content-Type: application/json' \
  --data '{}'

--data 会让 curl 发送 POST 请求。示例中的 {} 只是占位数据，应替换为端点要求的内容，并按原接口要求补充认证信息。命令没有使用 -L，便于发现额外的重定向。

检查响应内容，并在服务端确认实际收到的请求方法和请求体。不能仅凭 HTTP 200 响应就认定路由和业务处理均正确。

不生效时检查什么

若返回 Web 服务器的 404 页面，先检查 /api/log 是否被转交给 WordPress 的 index.php。WordPress 内部规则只能处理已经进入 WordPress 的请求。
若返回 WordPress 页面或 404，检查是否已刷新固定链接，以及是否有其他规则或同路径资源抢先处理请求。
若返回 REST API 错误，检查 /api/log 路由是否注册、是否支持 POST，以及认证和权限检查是否通过。
若 WordPress 安装在子目录，而硬编码地址位于网站根路径，需要在 Web 服务器或反向代理层将该地址内部转交给 WordPress 入口。具体配置取决于部署方式。

对于这个固定地址，添加精确的入口映射即可满足需求，无需全局修改 REST API 前缀。如果采用 HTTP 重定向，还需要确认调用程序能否跟随重定向并正确重发 POST。调用端无法调整时，内部重写更合适。