WP API — Использование WordPress REST API

27 мая 2015 года в еженедельном выпуске WordPress Мэтт Малленвег, один из соучредителей WordPress, заявил, что API WP REST будет «огромным и революционным для разработчиков». Разработчики смогут «создавать приложения против него изолированно».

Мэтт сделал все возможное, чтобы подчеркнуть, что «это действительно потрясающе, когда оно сочетается с чем-то другим. Представьте себе будущую версию HappyTables … где они вообще не изменяют WP admin. Он просто создает пользовательский интерфейс, который взаимодействует исключительно с REST API. Вместо того, чтобы пытаться взломать все в WP admin ».

Мэтт продолжил, сказав: «Я думаю, что REST API — это начало того, что администратор WP стал лишь одним из многих клиентов для управления WordPress. Думайте о WP admin как о PHP, плюс HTML, плюс клиенты JavaScript. Я думаю, что вы увидите местных клиентов. Я думаю, вы увидите чистых клиентов JavaScript. Я думаю, вы увидите других клиентов PHP, HTML, JS; возможно, в духе HappyTables или других вертикалей, возникших вокруг WordPress ». Он считает, что это может «сделать админ [панель инструментов] чем-то, что вы можете заменить так же легко, как и темами».

Высоко Расширяемый

Возможность WP API удаленного доступа и управления ресурсами сайта WordPress сама по себе достаточно крута, но ее расширяемость делает ее еще более увлекательной. WP API предоставляет способы как добавления дополнительных полей к ресурсам, так и добавления конечных точек в API.

Добавление полей к ресурсам

Используя функцию register_api_field, вы можете добавить дополнительные поля, которые будут обновляться или извлекаться при выполнении запросов к определенным ресурсам WP API. Сначала вам нужно запустить функцию add_action и использовать rest_api_init в качестве ловушки (вы, вероятно, добавили бы этот код через плагин WordPress). Второй параметр — это имя функции, которая запускается при обнаружении ловушки. Имя функции в этом случае — register_post_custom_field. custom_field — это имя поля, post — ресурс, а get_custom_field — функция обратного вызова, которая запускается при вызове GET-запроса для ресурса post.

function register_post_custom_field() { register_api_field( 'post', 'custom_field', array( 'get_callback' => 'get_custom_field', 'update_callback' => null, 'schema' => null, ) ); } 

Затем вам нужно добавить функцию обратного вызова get_custom_field в тот же файл. В этой функции (как вы можете видеть ниже) вы получаете значение «custom_field» для ресурса post и возвращаете его. Это делается для того, чтобы при вызове для получения значения настраиваемого поля в ответ вы получали значение настраиваемого поля.

 function get_custom_field( $object, $field_name, $request ) { return get_post_meta( $object[ 'id' ], $field_name, true ); } 

Добавление конечных точек

Согласно wp-api.org, «конечные точки — это функции, доступные через API. Это могут быть такие вещи, как обновление сообщения или удаление комментария. Конечные точки выполняют определенную функцию, принимая некоторое количество параметров и возвращая данные клиенту. Маршрут — это «имя», которое вы используете для доступа к конечным точкам, используемое в URL. Маршрут может иметь несколько конечных точек, связанных с ним, и то, какое использование зависит от глагола HTTP ».

Помимо добавления полей к ресурсам по умолчанию, вы можете зарегистрировать пользовательские конечные точки, которые будут использоваться с WP API. Чтобы зарегистрировать пользовательские конечные точки, вам нужно вызвать функцию add_action и использовать хук rest_api_init и функцию register_rest_route (опять же, вы, вероятно, добавили бы этот код в плагин WordPress). В приведенном ниже примере маршрут author / {author_id} зарегистрирован и определена конечная точка GET для этого маршрута (функция обратного вызова — get_post_title_by_author).

 add_action( 'rest_api_init', function () { register_rest_route( 'myplugin/v1', '/author/(?P \d+)', array( 'methods' => 'GET', 'callback' => 'get_post_title_by_author' ) ); } );  add_action( 'rest_api_init', function () { register_rest_route( 'myplugin/v1', '/author/(?P \d+)', array( 'methods' => 'GET', 'callback' => 'get_post_title_by_author' ) ); } );  

Ниже приведена функция обратного вызова, которая вызывается при доступе к конечной точке GET через WP API. К вашему сведению, сообщения извлекаются по идентификатору автора сообщения в этой функции, и возвращается последнее название сообщения.

 function get_post_title_by_author( $data ) { $posts = get_posts( array( 'author' => $data['id'], ) ); if ( empty( $posts ) ) { return null; } return $posts[0]->post_title; } 

Возможность добавления конечных точек и полей к функциональности WP API по умолчанию упрощает разработчикам использование API WP на многих различных типах сайтов WordPress и предоставляет больше итеративных возможностей в будущем.

Ограничения

Существуют некоторые важные ограничения, которые необходимо учитывать перед началом работы с WP API. Прежде всего, любая форма Сериализированных метаданных не может быть прочитана или сохранена с использованием WP API. Создатели API говорят, что это потому, что «JSON не может хранить все форматы данных, хранящихся в PHP» (например, пользовательские объекты PHP не могут быть представлены), сериализованные данные могут также представлять частные данные, а сериализованные данные имеют проблемы с безопасностью ( в частности, уязвимости удаленного выполнения кода).

Кроме того, защищенная мета не может быть доступна или сохранена через WP API. Защищенная мета — это любое метаполе, ключ которого начинается с символа _ (подчеркивание). Эти мета поля не могут быть предоставлены через API.

Все остальные метаданные доступны только в том случае, если «аутентифицированы с разрешением на редактирование сообщения, к которому прикреплена мета». Это связано с тем, что любой пользователь может вводить мета-значения через метабокс пользовательских полей и хочет защитить конфиденциальность пользователей.

 http://www.your-web-site.com/wp-json/wp/v2/posts 

 http://www.your-web-site.com/wp-json/wp/v2/posts/{id}