Посмотрите на WordPress HTTP API: wp_remote_get — Ответ

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

Отсюда мы можем написать подробные запросы; однако это только половина — есть и ответ.

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

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

Посмотрите на ответ

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

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

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

Пример ответа

Чтобы подготовить почву для того, что ожидать, давайте рассмотрим пример ответа. Допустим, вы должны отправить запрос GET на URL, который вернет вам простой текст.

Вообще говоря, вы можете ожидать более сложные запросы, когда ответом может быть XML или JSON или что-то еще; однако вся эта информация будет указана в индексе body массива ответов. Итак, если вы понимаете, чего ожидать, тогда вы понимаете, как с этим справиться.

С учетом сказанного, это ответ, который вы можете ожидать от простого запроса к домену, который не возвращает ничего, кроме простого текста.

Ничего, кроме массива (или, на самом деле, массива массивов). Ничего страшного, правда?

Давайте рассмотрим каждый из элементов ответа подробно.

Заголовки

Как видно из приведенного выше ответа, заголовки фактически состоят из другого массива, который состоит из другой информации.

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

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

С учетом сказанного, давайте рассмотрим каждый элемент заголовка подробно.

Дата

Понятно, что это исключительно простой для понимания элемент: проще говоря, это дата и время отправки сообщения. Очевидно, оно включает день, дату и время в среднем по Гринвичу времени, которое является мировым стандартом времени.

сервер

Элемент сервера относится к типу программного обеспечения, на котором работает сервер. Чаще всего вы видите Apache; однако сегодня существуют другие серверные приложения, такие как IIS и новый nginx.

X-Powered-By

X-Powered-By относится к серверному программному обеспечению, которое обеспечивает передачу данных. В нашем случае мы видим PHP, который просто означает, что наш запрос был отправлен на сервер с Apache и PHP.

Впрочем, это не всегда так.

Например, вы можете в конечном итоге обмениваться данными с сервером под управлением nginx и Python или с другим типом серверного программного обеспечения под управлением Ruby on Rails.

X-сервер

Этот конкретный элемент ответа относится к IP-адресу сервера, на который отправляется запрос. Мне редко нужно было знать эту конкретную информацию; однако, если вы в конечном итоге получите неожиданный ответ, несмотря на тот факт, что вся другая информация выглядит по порядку, это может помочь узнать, соответствует ли IP-адрес сервера тому, что вы ожидаете для домена, в который отправляется запрос.

Истекает

Всякий раз, когда делается запрос и отправляется ответ, у ответа, так сказать, есть время жизни.

Более конкретно, ответ будет считаться «устаревшим» через определенный промежуток времени. Очевидно, что время, когда ответ считается устаревшим, считается, что срок действия ответа истек.

Время, в течение которого ответ считается нестандартным, зависит от конфигурации сервера, но временная метка имеет тот же формат, что и дата запроса.

Cache-Control

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

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

Это очевидно состоит из двух индексов:

1. Первый индекс содержит информацию о том, был ли установлен no-cache
2. Второй индекс содержит информацию, если данные были кэшированы. Проще говоря, если post-check и интервал pre-check истек, то будет запрашиваться более новая версия данных; в противном случае кэшированная версия будет восстановлена.

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

изменяться

Это значение заголовка аналогично заголовку Cache-Control в том смысле, что оно сообщает запрашивающим серверам, как обрабатывать аналогичные последующие запросы.

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

Таким образом, в приведенном выше примере мы указываем серверу, что наш клиент способен обрабатывать закодированную информацию.

Content-Length

Длина содержимого — это простое понятие с одним признаком: во-первых, оно просто определяет длину тела ответа.

Дело в том, что это происходит в 8-битных байтах. Это означает, что ответ не предоставляется в килобайтах, мегабайтах или любой другой форме данных, которую мы обычно видим.

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

соединение

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

Однако есть и другие альтернативы. Например, вы можете получить «keep-alive», который, очевидно, хочет поддерживать соединение в течение некоторого времени.

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

Тип содержимого

Это действительно относится только к запросам POST и PUSH . Короче говоря, это определяет тип тела запросов.

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

тело

Элемент body фактически содержит информацию, возвращаемую с сервера.

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

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

отклик

Ответ фактически ссылается на код ответа HTTP, отправленный с сервера обратно запрашивающему клиенту. Если вы не знакомы с кодами состояния HTTP, то я рекомендую проверить HTTPStat.us для действительно хорошей справки.

Короче говоря, ответ состоит из числового кода и текстового сообщения, чтобы указать результат запроса.

Код и сообщение

В приведенном выше примере вы можете видеть, что мы получили код состояния «200» и сообщение «ОК». Код и пара сообщений всегда должны быть синхронизированы друг с другом.

Это означает, что если вы получите «403», то вы также должны получить «Запрещено», или, если вы получите «404», то вы должны получить сообщение «не найден».

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

Печенье

Наконец, массив файлов cookie относится к любой информации, которая была отправлена ​​по сети, на основе файлов cookie, которые существуют между текущим клиентом и сервером, осуществляющим связь.

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

Вывод

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

Если в вашей работе все хуже и хуже, вы всегда можете использовать отладчик или просто поместить некоторые операторы отладки, такие как print_r или var_dump , чтобы увидеть, что сервер возвращает, чтобы вы могли корректно обработать ошибки.

Позже мы вернемся к HTTP-API WordPress, чтобы изучить другие методы, такие как wp_remote_post и wp_remote_request чтобы получить полную картину HTTP-API.

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