WordPress REST API

WordPress REST API

WordPress REST API — это тема, которая вызвала ажиотаж с выпуском WordPress 4.7 и версии 2 рассматриваемого API..

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

Вдохновение

Недавно я прочитал статью Марка Цукерберга Building Jarvis и решил попробовать сделать бота FB Messenger, уроки которого для начала можно найти на https://magadanski.com/. Намного более ограниченный, чем Джарвис.

Для этого я начал с примера кода для роботов Facebook Messenger на основе Node.js. Я загрузил пример Heroku и дошел до того, что мне нужно найти способ именно поиска по сайту. Благодаря официальному выпуску WP REST API V2 как части ядра WordPress 4.7 менее месяца назад я решил воспользоваться.

Потребность в WP REST API

С его помощью вы можете получать последние сообщения в блогах с сайта WordPress. Достаточно добавить: / wp-json / wp / v2 / posts / после домашнего адреса. Поскольку это может сделать каждый, этот API конечной точки является полностью общедоступным. Как RSS-канал.

Мы пока не будем рассматривать другие конечные точки, но мы остановимся немного больше только на этой..

Все аргументы, которые можно передать WP_Query, можно добавить как параметр фильтра. Это делается как: / wp-json / wp / v2 / posts /? Filter [posts_per_page] = 1. Этот пример вернет только 1 результат (прочтите статью перед тестированием). Если вы хотите объединить с другим параметром (например, поиском), вы можете использовать / wp-json / wp / v2 / posts /? Filter [posts_per_page] = 1filter [s] = keyword. Не забудьте указать пробелы и специальные символы в URL.

Проблема в том, что если вы откроете https://magadanski.com/wp-json/wp/v2/posts/?filter[s ]=markdown, вы увидите то же самое, что и на https://magadanski.com/. wp-json / wp / v2 / posts /. Почему это происходит? Почему спрос ничего не меняет?

Общедоступные и частные конечные точки API

Оказывается, чтобы применить любой из этих фильтров, вам нужно авторизоваться. В противном случае вы можете увидеть только несколько последних статей (в соответствии с настройками сайта). Неприятно то, что мне потребовалось 2 часа болтовни, чтобы узнать, что это так. Нет сообщения об ошибке, просто результат, которого вы не ожидаете.

Читать также:  Начало работы в HTML некоторые основные теги

Я понимаю изменение количества отображаемых статей. Если кто-то просто введет -1, а ваш сайт находится в очень большом информационном агентстве с десятками тысяч статей, оперативная память сервера закончится и выйдет из строя. Другая проблема заключается в том, что такую ​​внутреннюю защиту можно выполнить с помощью простейшей проверки min (get_option (‘posts_per_page’), $ api_requested_parameter), где $ api_requested_parameter — это запрошенное вами значение. Таким образом вы отправите не больше, чем указано в настройках сайта, но и не больше запрошенных..

Это делает Facebook Open Graph API. Он никогда не возвращает более 20 результатов на страницу, но если вы попросите 10 — он вернет только столько результатов..

Однако я понимаю, что WP REST API — это что-то новое, и может потребоваться некоторое время, чтобы его сгладить. Так что проявив терпение и вклад;), мы, вероятно, доберемся до цели.

Что меня по-прежнему разочаровывает, так это то, что поиск не является публичным. Наконец, любой может открыть домашний адрес сайта WordPress и добавить ключевое слово? S =. Основной поиск полностью публичный. Видимо причина в том, что все аргументы WP_Query в одной чаше — запрещенные..

Проблемы с WP REST API

Я предупреждаю вас, что приведенные ниже примеры будут основаны на cURL, потому что я не хочу, чтобы они были строго специфичными для языка и платформы..

Согласно документации WP REST API, мы можем авторизоваться через OAuth, пароли приложений или обычную аутентификацию..

Короче говоря, OAuth требует дополнительных настроек, и, поскольку я был только в среде разработки для своего бота, я решил быстро протестировать с помощью паролей приложений. Эта и базовая аутентификация почти идентичны. Просто с помощью паролей приложений он создает пользователя для сайта со своим собственным паролем, который активен только для REST API. В противном случае в обоих случаях имя пользователя / пароль необходимо добавить в заголовок запроса «Авторизация»..

Так что либо:

curl —user "имя пользователя: пароль" ‘https://magadanski.com/wp-json/wp/v2/posts?filter\[s\ ]=markdown’

или (лучше — в кодировке base64):

curl ‘https://magadanski.com/wp-json/wp/v2/posts/?filter\[s\ ]=markdown’ -H ‘Авторизация: базовая {base64 (имя пользователя: пароль)}’

Читать также:  Шоу прокрутки (Часть 1 HTML + CSS)

Не то, чтобы есть функция {base64 ()} — я просто указал, что строка username: password должна быть закодирована так.

Вы также можете заметить "\" перед квадратными скобками — это необходимо для работы cURL..

Вам нужны плагины для входа в систему

Однако для обоих типов авторизации заголовков необходимо установить дополнительный плагин WordPress. У меня нет проблем — я работал, но плагин Application Passwords не работал. Поскольку я не был уверен, в чем причина, я решил попробовать установить оба, так как предполагал, что они могут работать только в сочетании. Однако это не решило проблему, и запросы cURL остались на публичном уровне..

Поскольку я не был уверен, как именно отлаживать авторизацию WP REST API, я решил просто попробовать OAuth — хотя для этого требовалась дополнительная настройка, это казалось более простым вариантом, чем отладка..

Я установил третий плагин, в котором нуждался OAuth, но оказалось, что у меня он почему-то не работает. При создании новой пары ключей у меня только что появилась ошибка с текстом: «Вы уверены, что хотите продолжить?» Без ссылки или чего-то еще. Просто текст wp_die () был вопросом, как будто у меня был выбор. Я предполагаю, что это связано с ошибкой перевода, которую я проверю через несколько дней. Итак, третий и последний метод был отброшен.

Еще через 2 часа поиска информации я пришел к списку проблем на GitHub для WP-API..

Почему именно GitHub? В любом случае — это не имеет большого значения.

Многие жалуются на проблемы с авторизацией

Однако после прочтения написанных там задач выяснилось, что на самом деле 8 из 17 открытых заявок связаны с одной и той же проблемой. Та же проблема, что и у меня. Он описан в выпуске №1 от апреля 2014 года (2 с половиной года назад!). Я также заметил, что последняя активность по проекту на GitHub довольно старая. Даже в выпуске №38 просто спрашивается, просматривают ли еще этот GitHub. Возможно, было бы лучше сообщать об этом просто по адресу https://core.trac.wordpress.org/tickets/active. И я сделаю это через несколько дней.

Читать также:  Начало работы с CSS

Пользовательская конечная точка

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

Документация WP REST API помогла мне больше в этом вопросе с хорошего старта. Если вы не читаете все, вот несколько простых советов, как добиться результата (имейте в виду, что он ограничен):

в этом

Начнем со ссылки на действие rest_api_init.

add_action (‘rest_api_init’, ‘my_custom_function’);

Собственный маршрут

Затем мы добавляем к этому действию новый маршрут отдыха, используя:

функция my_custom_function () {register_rest_route (‘пространство имен / версия’, ‘конечная точка / (? Pparams>. *)’, массив (‘методы’ => ‘GET’, ‘callback’ => ‘my_custom_callback’)); }

пространство имен / версия должны присутствовать, чтобы избежать конфликтов с другими плагинами или темами. Хотя формат не обязательно состоит из двух слов, разделенных /, это хорошее соглашение, которое также налагается WP Core: / wp-json / wp / v2 /. wp-json оказывается REST API; wp / v2 — это пространство имен / версия.

Второй параметр — это регулярное выражение, определяющее, какой метод вызывать и с какими параметрами. В приведенном выше примере метод называется конечной точкой, и после "/" мы обнаруживаем, что все остальное — это просто параметр с именем "params"..

Затем у нас есть аргументы, что это запрос «GET» и что параметры будут переданы функции my_custom_callback..

функция my_custom_callback ($ data) {$ result = my_custom_handle_params ($ data [‘params’]);
вернуть результат $; }

Обработка обратного звонка

Наконец, у нас есть реализация функции обратного вызова, которая принимает аргумент match-nato из регулярного выражения. В нашем примере это все, что находится после конечной точки /, хранящееся в $ data [‘params’]. Мы можем обрабатывать эти данные любым способом и возвращать результат в виде объекта PHP. WordPress уже проверяет результат json_encode.

А чтобы все протестировать, мы можем просто открыть домашний адрес сайта в браузере и добавить: / wp-json / namespace / version / endpoint / params. Для меня это просто https://magadanski.com/wp-json/mf/v1/search/markdown, что скоро позволит мне завершить первую версию моего бота..

Понравилась статья? Поделиться с друзьями:
Что нужно знать пользователю?