概述
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。