路由和端點 · WordPress開發手冊

REST API為我們提供了一種將URI匹配到我們的WordPress安裝中的各種資源的方法。默認情況下，如果您啟用了漂亮的永久鏈接，則WordPress REST API“生活在/ wp-json /”。在我們的WordPress網站https://ourawesomesite.com上，我們可以通過向https://ourawesomesite.com/wp-json/發出GET請求來訪問REST API的索引。該索引提供有關可用于特定WordPress安裝的路由的信息，以及支持哪些HTTP方法以及注冊了哪些端點。 ## 路線與端點端點是通過API可用的功能。這可以是檢索API索引，更新帖子或刪除注釋。端點執行一個特定的功能，采取一些參數和返回數據到客戶端。路由是您用于訪問端點的“名稱”，用于URL中。一個路由可以有多個端點與它相關聯，哪個使用取決于HTTP動詞。例如，使用網址http://example.com/wp-json/wp/v2/posts/123： “route”是wp / v2 / posts / 123 - 路由不包括wp-json，因為wp-json是API本身的基本路徑。該路由有3個端點： - GET觸發一個get_item方法，將post數據返回給客戶端。 - PUT觸發update_item方法，使數據更新，并返回更新后的數據。 - DELETE觸發一個delete_item方法，將現在刪除的帖子數據返回給客戶端。 >[warning] 警報：在沒有很好的固定鏈接的站點上，路由替代地添加到URL作為rest_route參數。對于上述示例，完整的網址將是http://example.com/?rest_route=/wp/v2/posts/123 ## 創建端點如果我們想要創建一個返回短語“Hello World”的端點，當它接收到一個GET請求時，我們首先需要注冊該端點的路由。要注冊路由，您應該使用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時，我們現在可以看到我們的REST 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（）的第四個參數是一個布爾值，用于路由是否應該覆蓋現有路由。覆蓋參數也不能真正解決我們的問題，因為兩個路由都可以覆蓋，或者我們想要使用兩個路由來做不同的事情。這是我們的路線使用命名空間的地方。 ##命名空間添加命名空間到您的路由是非常重要的。 “核心”端點使用wp / v2命名空間。 >[warning] 警告：不要將任何東西放入wp命名空間中，除非您正在將端點合并成核心。在核心端點命名空間中有一些關鍵的事情要注意。命名空間的第一部分是wp，它代表供應商名稱; WordPress。對于我們的插件，我們將想要提供我們稱為命名空間的供應商部分的唯一名稱。在上面的例子中，我們使用了hello-world。跟隨供應商部分是命名空間的版本部分。 “核心”端點使用v2來表示WordPress REST API的版本2。如果您正在編寫一個插件，您可以通過簡單地創建新的端點并增加您提供的版本號來保持REST API端點的向后兼容性。這樣可以訪問原始v1和v2端點。命名空間后面的路由部分是資源路徑。 ## 資源路徑資源路徑應該表示端點與哪個資源相關聯。在上面我們使用的例子中，我們使用單詞來表示我們正在交互的資源是一個短語。為了避免任何沖突，我們注冊的每個資源路徑在命名空間中也應該是唯一的。資源路徑應用于定義給定命名空間內的不同資源路由。假設我們有一個插件來處理一些基本的電子商務功能。我們將有兩種主要的資源類型訂單和產品。訂單是對產品的請求，但它們不是產品本身。同樣的概念適用于產品。雖然這些資源是相關的，但它們并不一樣，每個資源都應該存在于單獨的資源路徑中。我們的路線最終會看到我們的電子商務插件：/ 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&lt;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&lt;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] +）到我們的資源路徑/產品。路徑變量是一個正則表達式。在這種情況下，它使用[\ d] +表示應該是任何數字字符至少一次。如果您使用資源的數字ID，那么這是一個很好的例子，說明如何使用路徑變量。當使用路徑變量時，我們現在必須小心，因為用戶輸入可以匹配什么。幸運的是，正則表達式將過濾出不是數字的任何東西。但是，如果請求的ID的產品不存在，該怎么辦？我們需要做錯誤處理。您可以在上面的代碼示例中看到我們處理錯誤的基本方法。當您在終端回調中返回WP_Error時，API服務器將自動處理向客戶端提供錯誤。雖然本節是關于路線，但是我們已經對端點進行了很多的介紹。端點和路由是相互關聯的，但它們絕對有區別。 ##端點端點是路由需要映射到的目的地址。對于任何給定的路由，您可以為其注冊多個不同的端點。我們將擴展我們的虛擬電子商務插件，以更好地顯示路由和端點之間的區別。我們將在/ wp-json / my-shop / v1 / products / route中創建兩個端點。一個端點使用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' ); ``` 根據我們用于路由/ wp-json / my-shop / v1 / products的HTTP方法，我們與不同的端點匹配，并且觸發不同的回調。當我們使用POST時，我們觸發prefix_create_product（）回調，當我們使用GET時，我們觸發prefix_get_products（）回調。有許多不同的HTTP方法，REST API可以使用它們中的任何一種。 ## HTTP方法 HTTP方法有時被稱為HTTP動詞。它們只是通過HTTP進行通信的不同方式。 WordPress REST API使用的主要功能有： GET應用于從API檢索數據。 POST應用于創建新資源（即用戶，帖子，分類）。 PUT應用于更新資源。 DELETE應用于刪除資源。應該使用選項來提供有關我們資源的上下文。重要的是要注意，每個客戶端都不支持這些方法，因為它們在HTTP 1.1中引入。幸運的是，API為這些不幸的情況提供了解決方法。如果要刪除資源但無法發送DELETE請求，則可以在請求中使用_method參數或X-HTTP-Method-Override標頭。您如何發送POST請求到https://ourawesomesite.com/wp-json/my-shop/v1/products/1?_method=DELETE。現在您將刪除產品編號1，即使您的客戶端無法在請求中發送適當的HTTP方法，也可能存在阻止DELETE請求的防火墻。 HTTP方法與路由和回調相結合，構成端點的核心。 ## 回調 REST API支持的端點目前只有兩種類型的回調方式：回調和permission_callback。主要回調應該處理與資源的交互。權限回調應該處理用戶對端點的訪問權限。您可以通過在注冊端點時添加其他信息來添加額外的回調。然后，您可以鉤入rest_pre_dispatch，rest_dispatch_request或rest_post_dispatch鉤子來觸發新的自定義回調。 ## 端點回調刪除端點的主要回調只能刪除資源并在響應中返回它的副本。創建端點的主要回調只能創建資源并返回與新創建的數據匹配的響應。更新回調應該僅修改實際存在的資源。讀取回調應該只檢索已經存在的數據。考慮到冪等概念是很重要的。在REST API的上下文中，Idempotence意味著如果向端點發出相同的請求，服務器將以相同的方式處理請求。想像一下，如果我們讀取的端點不是冪等的。每當我們向它提出請求時，我們的服務器狀態將被請求修改，即使我們只是試圖獲取數據。這可能是災難性的。任何時候有人從您的服務器中獲取數據，內部會發生變化。重要的是確保讀取，更新和刪除端點不具有令人討厭的副作用，并堅持要做的事情。在REST API中，冪等式的概念與HTTP方法而不是端點回調相關聯。使用GET，HEAD，TRACE，OPTIONS，PUT或DELETE的任何回調不應產生任何副作用。 POST請求不是冪等的，通常用于創建資源。如果你創建了一個冪等的創建方法，那么你只會創建一個資源，因為當你做同樣的請求時，服務器不會有更多的副作用。對于創建，如果您通過服務器發出相同的請求，則每次都應生成新的資源。為了限制端點的使用，我們需要注冊一個權限回調。 ## 權限回調權限回調對于使用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. 'permission_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' ); ``` 我們現在已經為此示例指定了一個過濾器參數。當我們請求端點時，我們可以將參數指定為查詢參數。如果我們向https://ourawesomesitem.com/my-colors/v1/colors?filter=blue發出GET請求，我們將只收回我們的集合中的藍色。您也可以將它們作為身體參數傳遞到請求正文中，而不是在查詢字符串中。要了解查詢參數和體參數之間的區別，您應該閱讀有關HTTP規范的內容。查詢參數實際上位于查詢字符串中的URL和body參數直接嵌入到HTTP請求的正文中。我們已經為我們的端點創建了一個參數，但是我們如何驗證參數是一個字符串，并判斷它是否匹配紅色，綠色或藍色的值。為此，我們需要為我們的參數指定一個驗證回調。 ## 驗證驗證和消毒對API的安全性至關重要。驗證回調（在WP 4.6+中），在消毒回調之前觸發。您應該使用validate_callback作為參數來驗證您正在接收的輸入是否有效。在參數由主回調處理之前，應該使用sanitize_callback來轉換參數輸入或清除參數中的不需要的部分。在上面的示例中，我們需要驗證過濾器參數是一個字符串，并且它與紅色，綠色或藍色的值匹配。讓我們看一下在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注冊端點的基礎知識。路由是我們的端點所在的URI。端點是回調，方法，參數和其他選項的集合。當使用register_rest_route（）時，每個端點映射到路由。默認端點可以支持各種HTTP方法，主要回調，權限回調和注冊的參數。我們可以注冊端點來覆蓋與WordPress交互的任何用例。端點作為與REST API的核心交互點，但還有許多其他要探索和理解的主題，以充分利用這個強大的API。