HTTP API

http-api-wordpress

Получение данных из API

GitHub предоставляет отличное API, которое не требует регистрации приложения, поэтому, чтобы продемонстрировать некоторые методы работы с API, примеры будут нацелены на GitHub API.

Получение данных производится невероятно просто в WordPress через функцию wp_remote_get(). Эта функция имеет следующие два аргумента:

  1. $url — ресурс, с которого будут получены данные. Должно быть в стандартном формате HTTP
  2. $args — опционально — Вы можете передать здесь массив аргументов, чтобы изменить поведение и заголовки, такие как куки, следование редиректов и т.д.

Ниже предполагаемые значения по-умолчанию, хотя они могут быть изменены с помощью параметра $args:

  • method – GET
  • timeout – 5 – Как долго ждать, прежде чем закончить попытку
  • redirection – 5 – Сколько раз следовать перенаправлениям
  • httpversion – 1.0
  • blocking – true – Должна ли остальная часть страницы ждать окончания загрузки до того, как операция будет завершена?
  • headers – array()
  • body – null
  • cookies – array()

Давайте использовать URL для учетной записи пользователя GitHub и посмотрим, какого рода информацию мы можем получить

$response будет содержать все заголовки, контент и другие мета-данные по нашему запросу:

Получение тела ответа

Только тело ответа можно получить с помощью wp_remote_retrieve_body(). Эта функция принимает только один параметр, ответ от любой из других wp_remote_X функций.

Используя ресурс GitHub из предыдущего примера, $body будет

Если у вас нет каких-либо других операций для выполнения, кроме получения тела ответа, вы можете уменьшить код до одной линии:

Многие из вспомогательных функций могут быть использованы на одной линии аналогично.

Получение кода ответа

Вы можете проверить код ответа, чтобы убедиться, что возврат был успешным. Это может быть сделано с помощью функции wp_remote_retrieve_response_code():

В случае успеха $http_code будет содержать 200.

Получение конкретного заголовка

Если вы желаете получить конкретный заголовок, например, last-modified, вы можете сделать это с wp_remote_retrieve_header(). Эта функция принимает два параметра:

  1. $response – ответ от вызова get
  2. $header – название заголовка для получения

Чтобы получить last-modified заголовок (дата последнего изменения):

$last_modified будет содержать [last-modified] => Fri, 05 Oct 2012 04:39:58 GMT
Вы также можете получить все заголовки в массив с помощью wp_remote_retrieve_headers( $response ).

GET, используя базовую аутентификацию

API, которые более защищены, предоставляют один или более различных типов аутентификации. Распространенный, хотя и не очень безопасный метод аутентификации — HTTP Basic Authentication. Он может быть использован в WordPress, передавая Authorization ко второму параметру функции wp_remote_get(), также как и другие функции метода HTTP.

Передача данных в API

Те же вспомогательные методы (wp_remote_retrieve_body(), и т.д.) доступны для всех вызовов методов HTTP и используются в той же манере.

Передача данных делается с помощью wp_remote_post() функции и принимает точно такие же параметры, как wp_remote_get(). Следует отметить здесь, что вы должны передать ВСЕ элементы в массиве для второго параметра. Кодекс предусматривает допустимые значения по умолчанию. Вам нужно только заботиться о данных, которые вы отправляете, так что другие значения будут по-умолчанию.

Чтобы отправить данные на сервер вам нужно построить ассоциативный массив данных. Эти данные будут назначены «body» значению. С серверной стороны значение появится в переменной $_POST, как и можно было бы ожидать. То есть, если body => array( 'myvar' => 5 ) то на сервере $_POST['myvar'] = 5.

Поскольку GitHub не позволяет передачу данных на API, используемого в предыдущем примере, этот пример будет делать вид, что такое позволение есть. Обычно, если вы хотите передавать данные на API вам нужно будет связаться с поддержкой API и получить ключ API или какую-либо другую форму маркера аутентификации. Это просто доказывает, что ваше приложение имеет право манипулировать данными на API, подобно, как пользователь авторизуется на веб-сайте.

Давайте предположим, мы передаем контактную форму со следующими полями: имя, электронная почта, тема, комментарий. Для установки тела мы делаем следующее:

Теперь нам нужно настроить остальные значения, которые будут переданы в качестве второго параметра wp_remote_post():

Затем, конечно, сделать вызов:

Для тех из вас, кто не любит склеивание кусков кода, здесь весь фрагмент

Препятствие использования пропускной способности

Это может быть очень важно и иногда требуется самим API, проверить статус ресурса, используя HEAD перед получением самого ресурса. На высоко-нагруженных API, GET часто ограничивается числом запросов в минуту или в час. Там нет необходимости даже пытаться получить запрос, пока HEAD запрос не покажет, что данные на API были обновлены.

HEAD содержит информацию о том, были обновлены данные или нет, если данные должны быть в кэше, когда истекает срок сохраненной копии, а иногда и ограничение скорости на запросы к API.

Возвращаясь к примеру с GitHub, вот несколько примечательных заголовков. Большинство из этих заголовков являются стандартными, но вы всегда должны проверять документацию API, чтобы понять, как заголовки именуются и их назначение.

  • x-ratelimit-limit – Количество запросов, разрешенных в период времени
  • x-ratelimit-remaining – количество оставшихся доступных запросов в период времени
  • content-length – Величина контента в байтах. Может быть полезно, чтобы предупредить пользователя, если содержание достаточно велико
  • last-modified – Когда ресурс был последний раз изменен. Очень полезно для инструментов кеширования
  • cache-control – Как клиенту следует кешировать ресурс

Следующее будет проверять значение HEAD учетной записи пользователя GitHub:

$response должен выглядеть примерно так:

Все вспомогательные функции могут быть использованы и здесь. Исключение здесь в том, что HEAD никогда не возвращает тело (body), так что этот элемент всегда будет пустым.

Сделать любой тип запроса

Если вам нужно сделать запрос, используя метод HTTP, который не поддерживается ни одной из указанных выше функций, не паникуйте. Люди, развивающие WordPress, уже подумали об этом и предлагают wp_remote_request(). Эта функция принимает те же два параметра, как wp_remote_get() и позволяет также указать метод HTTP. Какие данные необходимо передать с вашим методом зависит от самого метода.

Чтобы отправить DELETE метод, пример может выглядеть так:

Введение в кэширование

Кэширование — это практика, посредством которой часто используемые объекты или объекты, требующие значительного времени на создание, сохраняются в быстром хранилище объектов для быстрого поиска при последующих запросах. Это предотвращает необходимость тратить время на выборку и необходимость снова строить объект. Кэширование — обширная тема, которая является частью оптимизации сайта и может растянуться на целую серию статей. Далее речь пойдет о введение в кэширование и простой, но эффективный способ быстро настроить кэш ответов API.

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

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

Когда следует кэшировать?

Если коротко, то ВСЕГДА, но опять же, есть случаи, когда нет необходимости. Если вы имеете дело с данными в реальном времени или в API конкретно указывается не кэшировать в заголовках, Вы можете не кэшировать, но для всех других ситуаций, как правило, хорошая идея, чтобы кэшировать любые ресурсы, получаемые от API.

Транзитное кэширование в WordPress

Транзитное кэширование WordPress (Transients) обеспечивают удобный способ хранения и использования кэшированных объектов. (Статья с примером использования). Transients живут в течение определенного времени, или до тех пор, пока вы не укажете, что они больше не нужны, когда ресурс от API был обновлен. Использование функциональности транзитного кэширования WordPress может быть простейшей в использовании системой кэширования, с которой вы когда-либо сталкивались. Есть всего три функции, чтобы сделать всю тяжелую работу за вас.

Кэшировать объект (Установить транзитное кэширование)

Кэширование объекта осуществляется с помощью set_transient() функции. Эта функция принимает следующие три параметра:

  1. $transient – Имя transient для дальнейшего использования
  2. $value – Значение transient
  3. $expiration – Количество секунд, через которое истечет срок действия transient

Пример кэширования информации пользователя GitHub на один час:

Получить объект в кэше (Получить transient)

Получение кэшированного объекта немного сложнее, чем установка transient. Вы должны запросить transient, но вы также должны проверить, истек ли срок действия transient, и если да, получить обновленные данные. Обычно вызов set_transient() сделан внутри вызова get_transient(). Вот пример получения данных транзитного кэширования для профиля пользователя GitHub:

Удалить объект в кэше (удалить transient)

Удаление кэшированных объект является самым легким из всех transient функций, просто передайте ей параметром имя transient, и готово.

Чтобы удалить данные пользователя GitHub:

Навигация по разделам:

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *