概述
REST API为我们提供了一种将URI与WordPress安装中的各种资源匹配的方法。默认情况下，如果您启用了非常固定链接，则WordPress Rest API“ Live”在/wp-json/。在我们的WordPress网站https://ourawesomesite.com，我们可以通过制作一个GET请求https://ourawesomesite.com/wp-json/。该索引提供有关该特定WordPress安装的可用路由的信息，以及支持哪些HTTP方法以及注册了哪些端点。
如果我们想创建一个端点，该端点将返回“ Hello World，这是WordPress REST API”，我们首先需要为该端点注册路由。要注册路线，您应该使用register_rest_route()功能。需要在rest_api_init动作钩。register_rest_route()处理通往端点的所有映射。让我们尝试创建一个“ Hello World，这是WordPress Rest API”路线。
/**
* This is our callback function that embeds our phrase in a WP_REST_Response
*/
function prefix_get_endpoint_phrase() {
// rest_ensure_response() wraps the data we want to return into a WP_REST_Response, and ensures it will be properly returned.
return rest_ensure_response( 'Hello World, this is the WordPress REST API' );
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_example_routes() {
// register_rest_route() handles more arguments but we are going to stick to the basics for now.
register_rest_route( 'hello-world/v1', '/phrase', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_endpoint_phrase',
) );
}
add_action( 'rest_api_init', 'prefix_register_example_routes' );第一个论点传入register_rest_route()是名称空间，它为我们提供了一种分组路线的方法。传递的第二个参数是资源路径或资源基础。就我们的示例而言，我们检索的资源是“ Hello World，这是WordPress Rest API”短语。第三个参数是一系列选项。我们指定端点可以使用哪些方法以及匹配端点时应该发生什么回调（可以做更多的事情，但这些是基本面）。
第三个参数还允许我们提供权限回调，该回调可以将端点的访问限制在某些用户中。第三个参数还提供了一种为端点注册参数的方法，以便请求可以修改我们端点的响应。我们将在本指南的端点部分中介绍这些概念。
当我们去https://ourawesomesite.com/wp-json/hello-world/v1/phrase现在，我们可以看到我们的休息API向我们致意。让我们深入了解路线。
路线
REST API中的路线由URI表示。路线本身就是所钉在末端的https://ourawesomesite.com/wp-json。API的索引路线是'/'这就是为什么https://ourawesomesite.com/wp-json/返回API的所有可用信息。所有路线都应在此路线上建造wp-json可以更改部分，但总的来说，建议保持相同。
我们要确保我们的路线是独一无二的。例如，我们可以有这样的书的路线：/books。我们的书籍路线现在将生活在https://ourawesomesite.com/wp-json/books。但是，这不是一个好的做法，因为我们最终会污染API的潜在途径。如果我们还想注册书籍路线，该怎么办？在这种情况下，我们会遇到很大的麻烦，因为这两条路线将相互冲突，只能使用一条路线。第四参数到register_rest_field()是该路线是否应覆盖现有路线的布尔值。
覆盖参数也不能真正解决我们的问题，因为这两种路线都可以覆盖，否则我们希望将这两种路线用于不同的事物。这是使用我们路线的名称空间的地方。
名称空间
在路线上添加名称空间非常重要。正在等待合并到WordPress核心的“核心”端点，使用/wp/v2名称空间。
/wp命名空间除非您制作端点以将其合并为核心。核心端点名称空间中有一些关键的事情要注意。名称空间的第一部分是/wp，代表供应商名称；WordPress。对于我们的插件，我们希望为我们所谓的名称空间的供应商部分提出唯一的名称。在上面的示例中，我们使用了hello-world。
遵循供应商部分是名称空间的版本部分。“核心”端点使用v2代表WordPress REST API的版本2。如果您正在编写插件，则可以通过简单地创建新的端点并凸起您提供的版本编号来使REST API端点的向后兼容。这两个原始v1和v2可以访问端点。
遵循命名空间的路由的一部分是资源路径。
资源路径
资源路径应表示端点与哪种资源相关联。在上面使用的示例中，我们使用了该词phrase表示我们正在与之交互的资源是一句话。为了避免任何碰撞，我们注册的每个资源路径也应在命名空间中唯一。资源路径应用于定义给定名称空间内的不同资源路由。
假设我们有一个可以处理一些基本电子商务功能的插件。我们将有两个主要的资源类型订单和产品。订单是对产品的要求，但它们不是产品本身。同样的概念也适用于产品。尽管这些资源是相关的，但它们不是同一回事，每个资源都应该生活在单独的资源路径中。我们的路线最终将在我们的电子商务插件中看起来像这样：/my-shop/v1/orders和/my-shop/v1/products。
使用这样的路线，我们希望每个人都返回订单或产品的集合。如果我们想通过ID获取特定产品，我们需要在路线中使用路径变量。
路径变量
路径变量使我们能够添加动态路由。为了扩展我们的电子商务路线，我们可以注册一条以获取单个产品的路线。
/**
* This is our callback function to return our products.
*
* @param WP_REST_Request $request This function accepts a rest request to process data.
*/
function prefix_get_products( $request ) {
// In practice this function would fetch the desired data. Here we are just making stuff up.
$products = array(
'1' => 'I am product 1',
'2' => 'I am product 2',
'3' => 'I am product 3',
);
return rest_ensure_response( $products );
}
/**
* This is our callback function to return a single product.
*
* @param WP_REST_Request $request This function accepts a rest request to process data.
*/
function prefix_get_product( $request ) {
// In practice this function would fetch the desired data. Here we are just making stuff up.
$products = array(
'1' => 'I am product 1',
'2' => 'I am product 2',
'3' => 'I am product 3',
);
// Here we are grabbing the 'id' path variable from the $request object. WP_REST_Request implements ArrayAccess, which allows us to grab properties as though it is an array.
$id = (string) $request['id'];
if ( isset( $products[ $id ] ) ) {
// Grab the product.
$product = $products[ $id ];
// Return the product as a response.
return rest_ensure_response( $product );
} else {
// Return a WP_Error because the request product was not found. In this case we return a 404 because the main resource was not found.
return new WP_Error( 'rest_product_invalid', esc_html__( 'The product does not exist.', 'my-text-domain' ), array( 'status' => 404 ) );
}
// If the code somehow executes to here something bad happened return a 500.
return new WP_Error( 'rest_api_sad', esc_html__( 'Something went horribly wrong.', 'my-text-domain' ), array( 'status' => 500 ) );
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_product_routes() {
// Here we are registering our route for a collection of products.
register_rest_route( 'my-shop/v1', '/products', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_products',
) );
// Here we are registering our route for single products. The (?P<id>[\d]+) is our path variable for the ID, which, in this example, can only be some form of positive number.
register_rest_route( 'my-shop/v1', '/products/(?P<id>[\d]+)', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_product',
) );
}
add_action( 'rest_api_init', 'prefix_register_product_routes' );以上示例涵盖了很多。要注意的重要部分是，在我们注册的第二个路线中，我们添加了一个路径变量/(?P[\d]+)到我们的资源路径/products。路径变量是正则表达式。在这种情况下，它使用[\d]+表示至少应该是任何数字字符。如果您正在为资源使用数字ID，那么这是如何使用路径变量的一个很好的示例。使用路径变量时，我们现在必须谨慎对待可以匹配的内容，因为它是用户输入的。
REGEX幸运的是，将滤除任何不数字的内容。但是，如果不存在请求ID的产品，该怎么办。我们需要进行错误处理。您可以在上面的代码示例中查看我们处理错误的基本方式。当你返回WP_Error在您的端点回调中，API服务器将自动处理向客户端的错误。
尽管本节是关于路线的，但我们已经介绍了很多有关端点的信息。终点和路线相互关联，但它们肯定有区别。
端点
端点是路由需要映射到的目的地。对于任何给定的路线，您可以注册许多不同的端点。我们将在虚构的电子商务插件上进行扩展，以更好地显示路线和端点之间的区别。我们将创建存在两个端点/wp-json/my-shop/v1/products/路线。一个端点使用http动词GET要获取产品，另一个端点使用http动词POST创建新产品。
/**
* This is our callback function to return our products.
*
* @param WP_REST_Request $request This function accepts a rest request to process data.
*/
function prefix_get_products( $request ) {
// In practice this function would fetch the desired data. Here we are just making stuff up.
$products = array(
'1' => 'I am product 1',
'2' => 'I am product 2',
'3' => 'I am product 3',
);
return rest_ensure_response( $products );
}
/**
* This is our callback function to return a single product.
*
* @param WP_REST_Request $request This function accepts a rest request to process data.
*/
function prefix_create_product( $request ) {
// In practice this function would create a product. Here we are just making stuff up.
return rest_ensure_response( 'Product has been created' );
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_product_routes() {
// Here we are registering our route for a collection of products and creation of products.
register_rest_route( 'my-shop/v1', '/products', array(
array(
// By using this constant we ensure that when the WP_REST_Server changes, our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_products',
),
array(
// By using this constant we ensure that when the WP_REST_Server changes, our create endpoints will work as intended.
'methods' => WP_REST_Server::CREATABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_create_product',
),
) );
}
add_action( 'rest_api_init', 'prefix_register_product_routes' );取决于我们用于路线的HTTP方法/wp-json/my-shop/v1/products，我们与其他端点匹配，并解雇了不同的回调。当我们使用时POST我们触发prefix_create_product()回调，当我们使用时GET我们触发prefix_get_products()打回来。
有许多不同的HTTP方法，其余API可以使用其中任何一个。
HTTP方法
HTTP方法有时称为HTTP动词。它们只是通过HTTP进行交流的不同方法。WordPress REST API使用的主要主要是：
GET应用于从API中检索数据。POST应该用于创建新资源（即用户，帖子，分类法）。PUT应该用于更新资源。DELETE应用于删除资源。OPTIONS应该用于提供有关我们资源的背景。
重要的是要注意，这些方法不受每个客户端的支持，因为它们是在HTTP 1.1中引入的。幸运的是，API为这些不幸的情况提供了解决方法。如果您想删除资源，但无法发送DELETE请求，然后您可以使用_method参数或X-HTTP-Method-Override按照您的要求。这是如何工作的POST请求https://ourawesomesite.com/wp-json/my-shop/v1/products/1?_method=DELETE。现在，即使您的客户端无法在请求中发送适当的HTTP方法，或者可能有一个阻止删除请求的防火墙，您也将删除产品编号1。
HTTP方法与路线和回调结合使用，构成了端点的核心。
回调
当前，对于由REST API支持的端点，目前只有两种类型的回调。callback和permissions_callback。主要回调应处理与资源的交互。权限回调应处理用户可以访问端点的内容。您可以在注册端点时添加其他信息来添加其他回调。然后您可以钩住rest_pre_dispatch，rest_dispatch_request，或者rest_post_dispatch挂钩以发射您的新自定义回调。
端点回调
删除端点的主要回调仅应删除资源并在响应中返回其副本。创建端点的主要回调只能创建资源并返回与新创建数据匹配的响应。更新回调只能修改实际存在的资源。阅读回调只能检索已经存在的数据。重要的是要考虑到掌握的概念。
在REST API的上下文中，IDEMETENCE意味着，如果您向端点提出相同的请求，则服务器将以相同的方式处理请求。想象一下，如果我们的读取端点不是动力。每当我们向其提出请求时，我们的服务器状态都会被请求修改，即使我们只是试图获取数据。这可能是灾难性的。每当有人从您的服务器中获取数据时，任何东西都会在内部发生变化。重要的是要确保阅读，更新和删除端点没有讨厌的副作用，而只是坚持他们的意图。
在REST API中，依从性的概念与HTTP方法相关联而不是端点回调。使用任何回调GET，HEAD，TRACE，OPTIONS，PUT，或者DELETE，不应产生任何副作用。POST请求不是掌握的，通常用于创建资源。如果您创建了一个didempotent创建方法，那么您只会创建一个资源，因为当您提出相同的请求时，服务器将不再有副作用。为了创建，如果您在服务器上和通过服务器上提出相同的请求，则每次都应生成新资源。
为了限制端点的使用情况，我们需要注册权限回调。
权限回调
权限回调对于使用WordPress REST API安全至关重要。如果您有任何不应公开显示的私人数据，则需要为您的端点注册权限回调。以下是如何注册权限回调的示例。
/**
* This is our callback function that embeds our resource in a WP_REST_Response
*/
function prefix_get_private_data() {
// rest_ensure_response() wraps the data we want to return into a WP_REST_Response, and ensures it will be properly returned.
return rest_ensure_response( 'This is private data.' );
}
/**
* This is our callback function that embeds our resource in a WP_REST_Response
*/
function prefix_get_private_data_permissions_check() {
// Restrict endpoint to only users who have the edit_posts capability.
if ( ! current_user_can( 'edit_posts' ) ) {
return new WP_Error( 'rest_forbidden', esc_html__( 'OMG you can not view private data.', 'my-text-domain' ), array( 'status' => 401 ) );
}
// This is a black-listing approach. You could alternatively do this via white-listing, by returning false here and changing the permissions check.
return true;
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_example_routes() {
// register_rest_route() handles more arguments but we are going to stick to the basics for now.
register_rest_route( 'my-plugin/v1', '/private-data', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_private_data',
// Here we register our permissions callback. The callback is fired before the main callback to check if the current user can access the endpoint.
'permissions_callback' => 'prefix_get_private_data_permissions_check',
) );
}
add_action( 'rest_api_init', 'prefix_register_example_routes' );如果您在未启用任何身份验证的情况下尝试此端点，则还将返回错误响应，从而阻止您查看数据。身份验证是一个重要的主题，最终将创建本章的一部分，以向您展示如何创建自己的身份验证过程。
争论
在向端点提出请求时，您可能需要指定额外的参数以更改响应。在注册端点时可以添加这些额外的参数。让我们看一下如何使用端点的参数的示例。
/**
* This is our callback function that embeds our resource in a WP_REST_Response
*/
function prefix_get_colors( $request ) {
// In practice this function would fetch the desired data. Here we are just making stuff up.
$colors = array(
'blue',
'blue',
'red',
'red',
'green',
'green',
);
if ( isset( $request['filter'] ) ) {
$filtered_colors = array();
foreach ( $colors as $color ) {
if ( $request['filter'] === $color ) {
$filtered_colors[] = $color;
}
}
return rest_ensure_response( $filtered_colors );
}
return rest_ensure_response( $colors );
}
/**
* We can use this function to contain our arguments for the example product endpoint.
*/
function prefix_get_color_arguments() {
$args = array();
// Here we are registering the schema for the filter argument.
$args['filter'] = array(
// description should be a human readable description of the argument.
'description' => esc_html__( 'The filter parameter is used to filter the collection of colors', 'my-text-domain' ),
// type specifies the type of data that the argument should be.
'type' => 'string',
// enum specified what values filter can take on.
'enum' => array( 'red', 'green', 'blue' ),
);
return $args;
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_example_routes() {
// register_rest_route() handles more arguments but we are going to stick to the basics for now.
register_rest_route( 'my-colors/v1', '/colors', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_colors',
// Here we register our permissions callback. The callback is fired before the main callback to check if the current user can access the endpoint.
'args' => prefix_get_color_arguments(),
) );
}
add_action( 'rest_api_init', 'prefix_register_example_routes' );我们现在指定了filter此示例的论点。当我们请求端点时，我们可以将参数指定为查询参数。如果我们做一个GET请求https://ourawesomesitem.com/my-colors/v1/colors?filter=blue，我们将仅退还我们系列中的蓝色。您也可以将它们作为请求正文中的主体参数传递，而不是在查询字符串中。要了解查询参数和身体参数之间的区别，您应该阅读有关HTTP规格的区别。查询参数生存在贴在URL上的查询字符串中，并且主体参数直接嵌入HTTP请求的主体中。
我们为终点创建了一个参数，但是我们如何验证该参数是字符串，并确定它是否与红色，绿色或蓝色值匹配。为此，我们需要为我们的参数指定验证回调。
验证
验证和消毒对于API的安全非常重要。验证回调（在WP 4.6+中），在消毒回调之前发射。你应该使用validate_callback为了验证您的参数是否有效。这sanitize_callback在主回调处理之前，应使用参数输入或清除参数中的不需要部分。
在上面的示例中，我们需要验证filter参数是一个字符串，它与红色，绿色或蓝色的值匹配。让我们看看添加后代码的样子validate_callback。
/**
* This is our callback function that embeds our resource in a WP_REST_Response
*/
function prefix_get_colors( $request ) {
// In practice this function would fetch more practical data. Here we are just making stuff up.
$colors = array(
'blue',
'blue',
'red',
'red',
'green',
'green',
);
if ( isset( $request['filter'] ) ) {
$filtered_colors = array();
foreach ( $colors as $color ) {
if ( $request['filter'] === $color ) {
$filtered_colors[] = $color;
}
}
return rest_ensure_response( $filtered_colors );
}
return rest_ensure_response( $colors );
}
/**
* Validate a request argument based on details registered to the route.
*
* @param mixed $value Value of the 'filter' argument.
* @param WP_REST_Request $request The current request object.
* @param string $param Key of the parameter. In this case it is 'filter'.
* @return WP_Error|boolean
*/
function prefix_filter_arg_validate_callback( $value, $request, $param ) {
// If the 'filter' argument is not a string return an error.
if ( ! is_string( $value ) ) {
return new WP_Error( 'rest_invalid_param', esc_html__( 'The filter argument must be a string.', 'my-text-domain' ), array( 'status' => 400 ) );
}
// Get the registered attributes for this endpoint request.
$attributes = $request->get_attributes();
// Grab the filter param schema.
$args = $attributes['args'][ $param ];
// If the filter param is not a value in our enum then we should return an error as well.
if ( ! in_array( $value, $args['enum'], true ) ) {
return new WP_Error( 'rest_invalid_param', sprintf( __( '%s is not one of %s' ), $param, implode( ', ', $args['enum'] ) ), array( 'status' => 400 ) );
}
}
/**
* We can use this function to contain our arguments for the example product endpoint.
*/
function prefix_get_color_arguments() {
$args = array();
// Here we are registering the schema for the filter argument.
$args['filter'] = array(
// description should be a human readable description of the argument.
'description' => esc_html__( 'The filter parameter is used to filter the collection of colors', 'my-text-domain' ),
// type specifies the type of data that the argument should be.
'type' => 'string',
// enum specified what values filter can take on.
'enum' => array( 'red', 'green', 'blue' ),
// Here we register the validation callback for the filter argument.
'validate_callback' => 'prefix_filter_arg_validate_callback',
);
return $args;
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_example_routes() {
// register_rest_route() handles more arguments but we are going to stick to the basics for now.
register_rest_route( 'my-colors/v1', '/colors', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_colors',
// Here we register our permissions callback. The callback is fired before the main callback to check if the current user can access the endpoint.
'args' => prefix_get_color_arguments(),
) );
}
add_action( 'rest_api_init', 'prefix_register_example_routes' );消毒
在上面的示例中，我们不需要使用sanitize_callback，因为我们将输入限制在枚举中的价值中。如果我们没有严格的验证并接受任何字符串作为参数，我们肯定需要注册sanitize_callback。如果我们想更新内容字段，并且用户输入了类似的内容alert('ZOMG Hacking you');。字段值可能是可执行的脚本。要剥离不需要的数据或将数据转换为所需的格式，我们需要注册一个sanitize_callback为了我们的论点。这是如何使用WordPress的示例sanitize_text_field()用于消毒回调：
/**
* This is our callback function that embeds our resource in a WP_REST_Response.
*
* The parameter is already sanitized by this point so we can use it without any worries.
*/
function prefix_get_item( $request ) {
if ( isset( $request['data'] ) ) {
return rest_ensure_response( $request['data'] );
}
return new WP_Error( 'rest_invalid', esc_html__( 'The data parameter is required.', 'my-text-domain' ), array( 'status' => 400 ) );
}
/**
* Validate a request argument based on details registered to the route.
*
* @param mixed $value Value of the 'filter' argument.
* @param WP_REST_Request $request The current request object.
* @param string $param Key of the parameter. In this case it is 'filter'.
* @return WP_Error|boolean
*/
function prefix_data_arg_validate_callback( $value, $request, $param ) {
// If the 'data' argument is not a string return an error.
if ( ! is_string( $value ) ) {
return new WP_Error( 'rest_invalid_param', esc_html__( 'The filter argument must be a string.', 'my-text-domain' ), array( 'status' => 400 ) );
}
}
/**
* Sanitize a request argument based on details registered to the route.
*
* @param mixed $value Value of the 'filter' argument.
* @param WP_REST_Request $request The current request object.
* @param string $param Key of the parameter. In this case it is 'filter'.
* @return WP_Error|boolean
*/
function prefix_data_arg_sanitize_callback( $value, $request, $param ) {
// It is as simple as returning the sanitized value.
return sanitize_text_field( $value );
}
/**
* We can use this function to contain our arguments for the example product endpoint.
*/
function prefix_get_data_arguments() {
$args = array();
// Here we are registering the schema for the filter argument.
$args['data'] = array(
// description should be a human readable description of the argument.
'description' => esc_html__( 'The data parameter is used to be sanitized and returned in the response.', 'my-text-domain' ),
// type specifies the type of data that the argument should be.
'type' => 'string',
// Set the argument to be required for the endpoint.
'required' => true,
// We are registering a basic validation callback for the data argument.
'validate_callback' => 'prefix_data_arg_validate_callback',
// Here we register the validation callback for the filter argument.
'sanitize_callback' => 'prefix_data_arg_sanitize_callback',
);
return $args;
}
/**
* This function is where we register our routes for our example endpoint.
*/
function prefix_register_example_routes() {
// register_rest_route() handles more arguments but we are going to stick to the basics for now.
register_rest_route( 'my-plugin/v1', '/sanitized-data', array(
// By using this constant we ensure that when the WP_REST_Server changes our readable endpoints will work as intended.
'methods' => WP_REST_Server::READABLE,
// Here we register our callback. The callback is fired when this endpoint is matched by the WP_REST_Server class.
'callback' => 'prefix_get_item',
// Here we register our permissions callback. The callback is fired before the main callback to check if the current user can access the endpoint.
'args' => prefix_get_data_arguments(),
) );
}
add_action( 'rest_api_init', 'prefix_register_example_routes' );概括
我们涵盖了WordPress REST API注册端点的基础知识。路线是我们的终点所居住的乌里斯。端点是回调，方法，ARG和其他选项的集合。使用时，每个端点都会映射到路由时register_rest_route()。默认情况下，端点可以支持各种HTTP方法，主回调，权限回调和注册参数。我们可以注册端点，以介绍我们的任何用例以与WordPress进行交互。终点是与REST API的核心交互点，但是还有许多其他主题需要探索和理解，可以充分利用这种功能强大的API。