Взгляд на API WordPress HTTP: краткий обзор wp_remote_post

В первой серии по API WordPress HTTP мы рассмотрели wp_remote_get . В частности, мы рассмотрели следующие аспекты API:

• Обзор функции
• Практический пример этого
• Как справиться с ответом
• И понимание аргументов для функции

Мы собираемся продолжить серию по API WordPress HTTP, но wp_remote_post наше внимание на второй метод API: wp_remote_post .

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

С учетом сказанного, давайте начнем наш обзор функции.

Удаленные запросы: обновление

Если вы не следили за этим до сих пор, я настоятельно рекомендую проверить самый первый пост в серии, чтобы хотя бы понять основы того, как работают запросы GET .

Честно говоря, запросы POST не так уж и отличаются. Так же, как GET запросы обычно используются для получения информации с сервера, POST запросы обычно предназначены для отправки сообщений на сервер.

Но вот в чем дело: оба протокола способны отправлять и получать данные, но вот общее практическое правило того, как я обычно подхожу к запросам GET и POST.

• GET запросы обычно используются для получения информации с сервера, поэтому ожидается ответ
• POST запросы обычно используются для отправки информации на сервер, и, хотя ответ может и не ожидаться, всегда приятно знать, правильно ли сервер получил и обработал ответ или нет

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

Краткое изложение того, как делаются запросы

Теперь, что касается запросов на уровне сервера — особенно в PHP — они обычно выполняются с учетом следующих двух функций (если только вы не используете стороннюю библиотеку, которая выходит за рамки этой серии).

Хотя мы рассмотрели их более подробно в первом посте, я кратко изложу их здесь.

• file_get_contents принимает URL-адрес в качестве параметра и возвращает запрашиваемые данные или ложь при ошибке. Это довольно распространенный способ получения данных для удаленных запросов.
• cURL — это целая библиотека (а не функция), которая предоставляет разработчикам полную конфигурацию для настройки в соответствии с их потребностями. Об этой библиотеке можно многое узнать. Если вы продвинутый разработчик, обязательно проверьте cURL.

По большей части, понимание того, как выполняются запросы, достаточно просто, но степень, в которой вы настраиваете запросы, полностью зависит от того, какой вариант вы выберете — то есть file_get_contents или cURL .

Конечно, это больше PHP-способ выполнения запросов, и хотя мы можем реализовывать это в некоторых из наших работ в зависимости от характера проекта, это не обязательно покрывает WordPress-способ выполнения этого.

Фактически, вышеупомянутое — это краткое повторение на основе предыдущего контента . Тем не менее, важно понимать, откуда мы пришли, что доступно и куда мы направляемся.

Как POST запросы в WordPress

Как уже упоминалось, приведенные выше заметки гораздо более тесно связаны с PHP, поэтому давайте взглянем на POST запросы в контексте WordPress.

И если вы занимаетесь созданием проектов для WordPress или продуктов поверх WordPress, важно понимать доступные API-интерфейсы, чтобы быть уверенным, что вы не потеряете какую-либо функцию или функциональность при обновлении до ядра. Приложение WordPress.

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

Для этого введите wp_remote_post .

Функция принимает два аргумента:

• URL, на который будет сделан запрос
• Массив аргументов, которые помогают адаптировать запрос к серверу.

Хотя массив аргументов будет несколько выходить за рамки того, что мы собираемся делать в этой серии, важно понимать, что доступно, особенно если вы собираетесь выполнять более продвинутую работу в будущем:

• method указывает, какой метод используется для запроса. Мы явно используем POST учитывая природу нашего метода API.
• timeout — это как долго вы готовы ждать обработки запроса, прежде чем сдаться. Значение по умолчанию составляет пять секунд, но его можно уменьшить или увеличить в зависимости от характера вашего приложения.
• redirection звучит так, как будто это URL, на который вы будете перенаправлены после завершения запроса, верно? Вместо этого это единица времени — в секундах — для ожидания перенаправления, прежде чем отказаться от запроса.
• user-agent позволяет нам контролировать user-agent, который отправляется вместе с запросом. Обычно это WordPress и номер версии, но он явно настраивается.
• короче говоря, если для этого параметра установлено значение true, сценарий будет продолжать выполняться до тех пор, пока что-то не будет возвращено с сервера; в противном случае скрипт продолжит работу, не задерживая остальную часть вашего приложения. Конечно, это происходит за счет того, что вы никогда не получите ответ, но в зависимости от условий, для которых вы строите, это может быть хорошо.
• compress было введено в WordPress 2.6 и позволяет отправлять тело запроса в сжатом формате. Это будет выходить за рамки наших будущих статей.
• decompress похожа на сжатие, за исключением того, что она на нашем конце — если сжатые данные получены, это позволит нам распаковать содержимое перед дальнейшей работой или обработкой.
• sslverify был представлен в WordPress 2.8 и полезен для сценариев, в которых вам нужно проверить, действительна ли SSL-сертификация. Если это не так, то запрос отклонен; в противном случае, ты в порядке. Эта опция также будет выходить за рамки этого набора статей.

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

Давайте POST запрос

На этом этапе все должно быть достаточно ясно, верно? Использование wp_remote_post должно быть таким же простым, как и использование wp_remote_get поэтому начиная с следующей статьи, мы собираемся сделать именно это.

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

Далее мы приступим к работе!