Безвозвратный user info php. Простой RESTful-сервис на нативном PHP. Преобразование строки к верхнему и нижнему регистру
февраль 5 , 2017
Я не знаю ни одного php-фреймворка. Это печально и стыдно, но законом пока не запрещено. А при этом поиграться с REST API хочется. Проблема в том, что php по умолчанию поддерживает только $_GET и $_POST. А для RESTful-сервиса надобно уметь работать еще и с PUT, DELETE и PATCH. И не очень очевидно, как культурно обработать множество запросов вида GET http://site.ru/users, DELETE http://site.ru/goods/5 и прочего непотребства. Как завернуть все подобные запросы в единую точку, универсально разобрать их на части и запустить нужный код для обработки данных?
Почти любой php-фреймворк умеет делать это из коробки. Например, Laravel, где роутинг реализован понятно и просто. Но что если нам не нужно прямо сейчас заниматься изучением новой большой темы, а хочется просто быстро завести проект с поддержкой REST API? Об этом и пойдет речь в статье.
Что должен уметь наш RESTful-сервис?
1. Поддерживать все 5 основных типов запросов: GET, POST, PUT, PATCH, DELETE.
2. Разруливать разнообразные маршруты вида
POST /goods
PUT /goods/{goodId}
GET /users/{userId}/info
и прочие сколь угодно длинные цепочки.
Внимание: это статья не про основы REST API
Я предполагаю, что Вы уже знакомы с REST-подходом и понимаете, как это работает.
Если нет, то в интернетах много замечательных статей по основам REST -
я не хочу дублировать их, моя идея - показать, как с REST работать на практике.
Какой функционал мы будем поддерживать?
Рассмотрим 2 сущности - товары и пользователи.
Для товаров возможности следующие:
- 1. GET /goods/{goodId} — Получение информации о товаре
- 2. POST /goods — Добавление нового товара
- 3. PUT /goods/{goodId} — Редактирование товара
- 4. PATCH /goods/{goodId} — Редактирование некоторых параметров товара
- 5. DELETE /goods/{goodId} — Удаление товара
По пользователям для разнообразия рассмотрим несколько вариантов с GET
- 1. GET /users/{userId} — Полная информация о пользователе
- 2. GET /users/{userId}/info — Только общая информация о пользователе
- 3. GET /users/{userId}/orders — Список заказов пользователя
Как это заработает на нативном PHP?
Первое, что мы сделаем - это настроим.htaccess так, чтобы все запросы перенаправлялись на файл index.php. Именно он и будет заниматься извлечением данных.
Второе - определимся, какие данные нам нужны и напишем код для их получения - в index.php.
Нас интересуют 3 типа данных:
- 1. Метод запроса (GET, POST, PUT, PATCH или DELETE)
- 2. Данные из URL-a, например, users/{userId}/info - нужны все 3 параметра
- 3. Данные из тела запроса
.htaccess
Создадим в корне проекта файл.htaccess
RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.+)$ index.php?q=$1
Этими загадочными строками мы повелеваем делать так:
1 - направить все запросы любого вида на царь-файл index.php
2 - сделать строку в URL-е доступной в index.php в get-параметре q.
То есть данные из URL-а вида /users/{userId}/info
мы достанем из $_GET["q"].
index.php
Рассмотрим index.php строка за строкой. Для начала получим метод запроса.
// Определяем метод запроса $method = $_SERVER["REQUEST_METHOD"];
Затем данные из тела запроса
// Получаем данные из тела запроса $formData = getFormData($method);
Для GET и POST легко вытащить данные из соответствующих массивов $_GET и $_POST. А вот для остальных методов нужно чуть извратиться. Код для них вытаскивается из потока php://input , код легко гуглится, я всего лишь написал общую обертку - функцию getFormData($method)
// Получение данных из тела запроса function getFormData($method) { // GET или POST: данные возвращаем как есть if ($method === "GET") return $_GET; if ($method === "POST") return $_POST; // PUT, PATCH или DELETE $data = array(); $exploded = explode("&", file_get_contents("php://input")); foreach($exploded as $pair) { $item = explode("=", $pair); if (count($item) == 2) { $data = urldecode($item); } } return $data; }
То есть мы получили нужные данные, скрыв все детали в getFormData - ну и отлично. Переходим к самому интересному - роутингу.
// Разбираем url $url = (isset($_GET["q"])) ? $_GET["q"] : ""; $url = rtrim($url, "/"); $urls = explode("/", $url);
Выше мы узнали, что.htaccess подложит нам параметры из URL-a в q-параметр массива $_GET. То есть в $_GET["q"] попадет примерно такая строка: users/10 . Независимо от того, каким методом мы запрос дергаем.
А explode("/", $url)
преобразует нам эту строку в массив, с которым уже можно работать.
Таким образом, составляйте сколько угодно длинные цепочки запросов, например,
GET /goods/page/2/limit/10/sort/price_asc
И будьте уверены, получите массив
$urls = array("goods", "page", "2", "limit", "10", "sort", "price_asc");
Теперь у нас есть все данные, нужно сделать с ними что-нибудь полезное. А сделают это всего лишь 4 строки кода
// Определяем роутер и url data $router = $urls; $urlData = array_slice($urls, 1); // Подключаем файл-роутер и запускаем главную функцию include_once "routers/" . $router . ".php"; route($method, $urlData, $formData);
Улавливаете? Мы заводим папку routers, в которую складываем файлы, манипулирующие одной сущностью: товарами или пользователями. При этом договариваемся, что название файлов совпадают с первым параметром в urlData - он и будет роутером, $router. А из urlData этот роутер нужно убрать, он нам больше не нужен и используется только для подключения нужного файла. array_slice($urls, 1) и вытащит нам все элементы массива, кроме первого.
Теперь осталось подключить нужный файл-роутер и запустить функцию route с тремя параметрами. Что же это за function route? Условимся, что в каждом файле-роутере будет определена такая функция, которая по входным параметрам определит, какое действие инициировал пользователь, и выполнит нужный код. Сейчас это станет понятнее. Рассмотрим первый запрос - получение данных о товаре.
GET /goods/{goodId}
Файл routers/goods.php
// Роутер function route($method, $urlData, $formData) { // Получение информации о товаре // GET /goods/{goodId} if ($method === "GET" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Вытаскиваем товар из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $goodId, "good" => "phone", "price" => 10000)); return; } // Возвращаем ошибку header("HTTP/1.0 400 Bad Request"); echo json_encode(array("error" => "Bad Request")); }
Содержимое файла - это одна большая функция route, которая в зависимости от переданных параметров выполняет нужные действия. Если метод GET и в urlData передан 1 параметр (goodId), то это запрос о получении данных о товаре.
Внимание: пример очень упрощенный
В реале, конечно же, нужно дополнительно проверять входные параметры, например, что goodId - это число.
Вместо того, чтобы писать код здесь, Вы, вероятно, подключите нужный класс.
И для получения товара создадите объект оного класса и вызовете у него какой-то метод.
А может быть, передадите управление какому-то контроллеру, который уже озаботится инициализацией нужных моделей.
Вариантов много, мы рассматриваем только общую структуру кода.
В ответе клиенту мы выводим нужные данные: название товара и его цену. id товара и метод в реальном приложении совершенно не обязательны. Покажем их только, чтобы убедится, что вызывается нужный метод с правильными параметрами.
Давайте попробуем на примере: откройте консоль браузера и выполните код
$.ajax({url: "/examples/rest/goods/10", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Код отправит запрос на сервер, где я развернул подобное приложение и выведет ответ.
Убедитесь, что интересующий наш маршрут /goods/10
действительно отработал.
На вкладке Network Вы заметите такой же запрос.
И да, /examples/rest - это корневой путь нашего тестового приложения на сайт
Если Вам привычнее пользоваться curl-ом в консоли, то запустите в терминале это - ответ будет тот же самый, да еще и с заголовками от сервера.
Curl -X GET https://сайт/examples/rest/goods/10 -i
В конце функции мы написали такой код.
// Возвращаем ошибку header("HTTP/1.0 400 Bad Request"); echo json_encode(array("error" => "Bad Request"));
Он значит, что если мы ошиблись с параметрами или запрашиваемый маршрут не определен, то вернем клиенту 400-ю ошибку Bad Request. Добавьте, например, к URL-у что-то вроде goods/10/another_param и увидите ошибку в консоли и ответ 400 - кривой запрос не прошел.
По http-кодам ответов сервера
Мы не будем заморачиваться с выводом разных кодов, хотя по REST-у это и стоит делать.
Клиентских ошибок много. Даже в нашем простом случае уместна 405 в случае неправильно переданного метода.
Намеренно не хочу усложнять.
В случае успеха сервер у нас всегда вернет 200 ОК.
По хорошему, при создании ресурса стоит отдавать 201 Created.
Но опять-таки в плане упрощения эти тонкости мы отбросим, а в реальном проекте Вы их легко реализуете сами.
По совести говоря, статья закончена. Думаю, Вы уже поняли подход, каким образом разруливаются все маршруты, вынимаются данные, как это протестировать, как добавлять новые запросы и т.д. Но я для завершения образа приведу реализацию оставшихся 7 запросов, которые мы обозначили в начале статьи. Попутно приведу пару интересных замечаний, а в конце выложу архив с исходниками.
POST /goods
Добавление нового товара
// Добавление нового товара // POST /goods if ($method === "POST" && empty($urlData)) { // Добавляем товар в базу... // Выводим ответ клиенту echo json_encode(array("method" => "POST", "id" => rand(1, 100), "formData" => $formData)); return; }
urlData сейчас пустой, но зато используется formData - мы ее просто выведем клиенту.
Как сделать "правильно"?
Согласно канонам REST в post-запросе следует отдавать обратно только id созданной сущности или url, по которому эту сущность можно получить.
То есть в ответе будет или просто число - {goodId}
, или /goods/{goodId}
.
Почему я написал "правильно" в кавычках? Да потому, что REST - это набор не жестких правил, а рекомендаций.
И как будете реализовывать именно Вы, зависит от Ваших предпочтений или уже принятых соглашений на конкретном проекте.
Просто имейте в виду, что другой программист, читающий код и осведомленный о REST-подходе,
будет ожидать в ответе на post-запрос id созданного объекта или url, по которому можно get-запросом вытащить данные об этом объекте.
Тестим из консоли
$.ajax({url: "/examples/rest/goods/", method: "POST", data: {good: "notebook", price: 20000}, dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X POST https://сайт/examples/rest/goods/ --data "good=notebook&price=20000" -i
PUT /goods/{goodId}
Редактирование товара
// Обновление всех данных товара // PUT /goods/{goodId} if ($method === "PUT" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Обновляем все поля товара в базе... // Выводим ответ клиенту echo json_encode(array("method" => "PUT", "id" => $goodId, "formData" => $formData)); return; }
Здесь уже все данные используются по-полной. Из urlData вытаскивается id товара, а из formData - свойства.
Тестим из консоли
$.ajax({url: "/examples/rest/goods/15", method: "PUT", data: {good: "notebook", price: 20000}, dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X PUT https://сайт/examples/rest/goods/15 --data "good=notebook&price=20000" -i
PATCH /goods/{goodId}
Частичное обновление товара
// Частичное обновление данных товара // PATCH /goods/{goodId} if ($method === "PATCH" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Обновляем только указанные поля товара в базе... // Выводим ответ клиенту echo json_encode(array("method" => "PATCH", "id" => $goodId, "formData" => $formData)); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/goods/15", method: "PATCH", data: {price: 25000}, dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X PATCH https://сайт/examples/rest/goods/15 --data "price=25000" -i
К чему эти понты с PUT и PATCH?
Разве одного PUT не достаточно? Разве не выполняют они одно и то же действие - обновляют данные объекта?
Именно так - внешне действие одно. Разница в передаваемых данных.
PUT предполагает, что на сервер передаются все
поля объекта, а PATCH - только измененные
.
Те, которые переданы в теле запроса.
Обратите внимание, что в предыдущем PUT мы передали и название товара, и цену.
А в PATCH - только цену. То есть мы отправили на сервер только измененные данные.
Нужен ли Вам PATCH - решайте сами. Но помните о том читающем код программисте, о котором я упоминал выше.
DELETE /goods/{goodId}
Удаление товара
// Удаление товара // DELETE /goods/{goodId} if ($method === "DELETE" && count($urlData) === 1) { // Получаем id товара $goodId = $urlData; // Удаляем товар из базы... // Выводим ответ клиенту echo json_encode(array("method" => "DELETE", "id" => $goodId)); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/goods/20", method: "DELETE", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X DELETE https://сайт/examples/rest/goods/20 -i
С DELETE-запросом все понятно. Теперь давайте рассмотрим работу с пользователями - роутер users и соответственно, файл users.php
GET /users/{userId}
Получение всех данных о пользователе. Если GET-запрос вида /users/{userId} , то мы вернем всю информацию о пользователе, если дополнительно указывается /info или /orders , то соответственно, только общую информацию или список заказов.
// Роутер function route($method, $urlData, $formData) { // Получение всей информации о пользователе // GET /users/{userId} if ($method === "GET" && count($urlData) === 1) { // Получаем id товара $userId = $urlData; // Вытаскиваем все данные о пользователе из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $userId, "info" => array("email" => "[email protected]", "name" => "Webdevkin"), "orders" => array(array("orderId" => 5, "summa" => 2000, "orderDate" => "12.01.2017"), array("orderId" => 8, "summa" => 5000, "orderDate" => "03.02.2017")))); return; } // Возвращаем ошибку header("HTTP/1.0 400 Bad Request"); echo json_encode(array("error" => "Bad Request")); }
Тестим из консоли
$.ajax({url: "/examples/rest/users/5", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X GET https://сайт/examples/rest/users/5 -i
GET /users/{userId}/info
Общая информация о пользователе
// Получение общей информации о пользователе // GET /users/{userId}/info if ($method === "GET" && count($urlData) === 2 && $urlData === "info") { // Получаем id товара $userId = $urlData; // Вытаскиваем общие данные о пользователе из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $userId, "info" => array("email" => "[email protected]", "name" => "Webdevkin"))); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/users/5/info", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X GET https://сайт/examples/rest/users/5/info -i
GET /users/{userId}/orders
Получение списка заказов пользователя
// Получение заказов пользователя // GET /users/{userId}/orders if ($method === "GET" && count($urlData) === 2 && $urlData === "orders") { // Получаем id товара $userId = $urlData; // Вытаскиваем данные о заказах пользователя из базы... // Выводим ответ клиенту echo json_encode(array("method" => "GET", "id" => $userId, "orders" => array(array("orderId" => 5, "summa" => 2000, "orderDate" => "12.01.2017"), array("orderId" => 8, "summa" => 5000, "orderDate" => "03.02.2017")))); return; }
Тестим из консоли
$.ajax({url: "/examples/rest/users/5/orders", method: "GET", dataType: "json", success: function(response){console.log("response:", response)}})
Curl -X GET https://сайт/examples/rest/users/5/orders -i
Итоги и исходники
Исходники из примеров статьи -
Как видим, организовать поддержку REST API на нативном php оказалось не так уж и сложно и вполне законными способами. Главное - это поддержка маршрутов и нестандартных для php методов PUT, PATCH и DELETE.
Основной код, реализовывающий эту поддержку, уместился в 3 десятка строк index.php. Остальное - это уже обвязка, которую можно реализовать как угодно. Я предложил это сделать в виде подключаемых файлов-роутеров, имена которых совпадают с сущностями Вашего проекта. Но можно подключить фантазию и найти более интересное решение.
Суперглобальный массив $_SERVER
Одним из важнейших предопределённых массивов является массив $_SERVER - в него PHP-интерпретатор помещает переменные, полученные от сервера. Без данных переменных сложно организовать полноценную поддержку Web-приложений. Ниже приводится описание наиболее важных элементов суперглобального массива $_SERVER.
Замечание
Просмотреть полный список элементов массива $_SERVER можно либо при помощи функции print_r(), которая распечатывает дамп массива либо при помощи функции phpinfo(), которая выводит информацию о PHP-интерпретаторе.
Элемент $_SERVER["DOCUMENT_ROOT"]
Элемент $_SERVER["DOCUMENT_ROOT"] содержит путь к корневой директории сервера, если скрипт выполняется в виртуальном хосте, в данном элементе указывается путь к корневой директории виртуального хоста. Т.е. в конфигурационном файле httpd.conf виртуальный хост имеет директиву DocumentRoot, которой присвоено значение "D:/main", элемент $_SERVER["DOCUMENT_ROOT"] будет содержать значение "D:main".
Элемент $_SERVER["HTTP_ACCEPT"]
В элементе $_SERVER["HTTP_ACCEPT"] описываются предпочтения клиента относительно типа документа. Содержимое этого элемента извлекается из HTTP-заголовка Accept, который присылает клиент серверу. Содержимое данного заголовка может выглядеть следующим образом
image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/msword, */*
Заголовок Accept позволяет уточнить медиа-тип, который предпочитает получить клиент в ответ на свой запрос. Этот заголовок позволяет сообщить серверу, что ответ ограничен небольшим множеством предпочитаемых типов.
Символ * используется для группирования типов в медиа-ряду. К примеру, символом */* задается использование всех типов, а обозначение type/* определяет использование всех подтипов выбранного типа type.
Замечание
Медиа-типы отделяются друг от друга запятыми.
Каждый медиа-ряд характеризуется также дополнительным набором параметров. Одним из них является так называемый относительный коэффициент предпочтения q, который принимает значения от 0 до 1, соответственно, от менее предпочитаемых типов к более предпочитаемым. Использование нескольких параметров q, позволяет клиенту сообщить серверу относительную степень предпочтения для того или иного медиа-типа.
Замечание
По умолчанию параметр q принимает значение 1. Кроме того, от медиа-типа он отделяется точкой с запятой.
Пример заголовка типа Accept:
Accept: audio/*; q=0.2, audio/basic
В данном заголовке первым идёт тип audio/* включающий в себя все музыкальные документы и характеризующийся коэффициентом предпочтения 0.2. Через запятую указан тип audio/basic, для которого коэффициент предпочтения не указан и принимает значение по умолчанию равное единице. Цитируя RFС2616 данный заголовок можно интерпретировать следующим образом: “Я предпочитаю тип audio/basic, но мне можно также слать документы любого другого audio-типа, если они будут доступны, после снижения коэффициента предпочтения более чем на 80 %”.
Пример может быть более сложным.
Accept: text/plain; q=0.5,
text/html,
text/x-dvi;
q=0.8, text/x-c
Замечание
Следует учитывать, что элемент $_SERVER["HTTP_ACCEPT"] содержит точно такую же информацию, но без начального заголовка Accept.
Этот заголовок интерпретируется следующим образом: Типы документов text/html и text/x-c являются предпочтительными, но если они недоступны, тогда клиент отсылающий данный запрос, предпочтёт text/x-dvi, а, если и его нет, то он может принять тип text/plain.
Элемент $_SERVER["HTTP_ACCEPT_LANGUAGE"]
В элементе $_SERVER["HTTP_ACCEPT_LANGUAGE"] описываются предпочтения клиента относительно языка. Данная информация извлекается из HTTP-заголовка Accept-Language, который присылает клиент серверу. Можно привести следующий пример:
Accept-Language: ru, en; q=0.7
Который можно интерпретировать следующим образом: клиент предпочитает русский язык, но в случае его отсутствия согласен принимать документы на английском. Элемент $_SERVER["HTTP_ACCEPT_LANGUAGE"] будет содержать точно такую же информацию, но без заголовка Accept-Language:
ru, en; q=0.7
Содержимое элемента $_SERVER["HTTP_ACCEPT_LANGUAGE"] можно использовать для определения национальной принадлежность посетителей. Однако результаты будут приблизительными, так как многие пользователи используют английские варианты браузеров, которые будут извещать сервер о том, что посетитель предпочитает лишь один язык - английский.
Элемент $_SERVER["HTTP_HOST"]
В элементе $_SERVER["HTTP_HOST"] содержится имя сервера, которое, как правило, совпадает с доменным именем сайта, расположенного на сервере. Как правило, имя, указанное в данном параметре совпадает с именем $_SERVER["SERVER_NAME"]. В параметре приводится лишь доменное имя без названия протокола (http://), т.е.
www.sofftime.ru
Элемент $_SERVER["HTTP_REFERER"]
В элементе $_SERVER["HTTP_REFERER"] приводится адрес страницы, с которой посетитель пришёл на данную страницу. Переход должен осуществляться по ссылке. Создадим две страницы index.php и page.php.
Страница index.php
echo
"Ссылка на страницу
PHP
"
;
echo
.
$_SERVER
[
"HTTP_REFERER"
]
?>
Страница page.php будет аналогичного содержания, но ссылка будет указывать на страницу index.php.
Страница page.php
echo
"Ссылка на страницу
PHP
"
;
echo
"Содержимое
$_SERVER["HTTP_REFERER"] - "
.
$_SERVER
[
"HTTP_REFERER"
]
?>
При переходе с одной страницы на другую, под ссылкой будет выводится адрес страницы, с которой был осуществлён переход.
Элемент $_SERVER["HTTP_USER_AGENT"]
Элемент $_SERVER["HTTP_USER_AGENT"] содержит информацию о типе и версии браузера и операционной системы посетителя.
Вот типичное содержание этой строки: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)". Наличие подстроки "MSIE 6.0" говорит о том, что посетитель просматривает страницу при помощи Internet Explorer версии 6.0. Строка "Windows NT 5.1" сообщает, что в качестве операционной системы используется Windows XP.
Замечание
Для Windows 2000 элемент $_SERVER["HTTP_USER_AGENT"] выглядит следующим образом: "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)")", в то время как для Windows XP - "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)".
Если посетитель воспользуется браузером Opera, то содержание $_SERVER["HTTP_USER_AGENT"]может выглядеть следующим образом: "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 6.04 ". Подстрока "MSIE 6.0" здесь так же присутствует, сообщая, что браузер Opera является совместимым с браузером Internet Explorer и использует те же динамические библиотеки Windows. Поэтому, при анализе строки, возвращаемой браузером, следует иметь в виду, что к Internet Explorer относится строка, содержащая подстроку "MSIE 6.0" и не содержащая подстроки "Opera". Кроме того, из данной строки можно заключить, что пользователь использует операционную систему Windows 98.
Замечание
Пользовательский агент браузера Firefox может выглядеть следующим образом Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5.
При использовании браузера Netscape, содержание элемент $_SERVER["HTTP_USER_AGENT"] может выглядеть следующим образом: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1". Принадлежность к этому браузеру можно определить по наличию подстроки "Netscape". Кроме того, можно узнать, что посетитель выходит в Интернет, используя операционную версию Linux, с ядром, оптимизированным под Pentium IV, находясь в графической оболочке X-Window. Этот механизм удобно использовать для сбора статистической информации, которая позволяет дизайнерам оптимизировать страницы под наиболее распространенные браузеры.
Элемент $_SERVER["REMOTE_ADDR"]
В элемент $_SERVER["REMOTE_ADDR"] помещается IP-адрес клиента. При тестировании на локальной машине - этот адрес будет равен 127.0.0.1. Однако при тестировании в сети переменная вернёт IP-адрес клиента или последнего прокси-сервера через который клиент попал на сервер. Если клиент использует прокси-сервер узнать его IP-адрес можно при помощи переменной окружения HTTP_X_FORWARDED_FOR, значение которой можно получить при помощи функции getenv().
Замечание
Прокси-сервера являются специальными промежуточными серверами, предоставляющими специальный вид услуг: сжатие трафика, кодирование данных, адаптация под мобильные устройства и т.п. Среди множества прокси-серверов различают так называемые анонимные прокси-сервера, которые позволяют скрывать истинный IP-адрес клиента, такие сервера не возвращают переменной окружения HTTP_X_FORWARDED_FOR.
Извлечение переменной окружения HTTP_X_FORWARDED_FOR
echo
getenv
(HTTP_X_FORWARDED_FOR
);
?>
Элемент $_SERVER["SCRIPT_FILENAME"]
В элемент $_SERVER["SCRIPT_FILENAME"] помещается абсолютный путь к файлу от корня диска. Так, если сервер работает под управлением операционной системы Windows, то такой путь может выглядеть следующим образом "d:main estindex.php", т.е. путь указывается от диска, в UNIX-подобной операционной системы путь указывается от корневой директории /, например "/var/share/www/test/index.php".
Элемент $_SERVER["SERVER_NAME"]
В элемент $_SERVER["SERVER_NAME"] помещается имя сервера, как правило, совпадающее с доменным именем сайта, расположенного на нём. Например,
www.softtime.ru
Содержимое элемента $_SERVER["SERVER_NAME"] часто совпадает с содержимым элемента $_SERVER["HTTP_HOST"]. Помимо имени сервера суперглобальный массив $_SERVER позволяет выяснить ещё ряд параметров сервера, например IP-адрес сервера, прослушиваемый порт, какой Web-сервер установлен и версию HTTP протокола. Эта информация помещается в элементы $_SERVER["SERVER_ADDR"], $_SERVER["SERVER_PORT"], $_SERVER["SERVER_SOFTWARE"] и $_SERVER["SERVER_PROTOCOL"], соответственно. Ниже приводится пример с использованием данных элементов.
Использование элементов массива $_SERVER
echo
"Имя сервера - "
.
$_SERVER
[
"SERVER_NAME"
].
"
"
;
echo
"IP-адрес сервера -
"
.
$_SERVER
[
"SERVER_ADDR"
].
"
"
;
echo
"Порт сервера -
"
.
$_SERVER
[
"SERVER_PORT"
].
"
"
;
echo
"Web-сервер -
"
.
$_SERVER
[
"SERVER_SOFTWARE"
].
"
"
;
echo
"Версия HTTP-протокола -
"
.
$_SERVER
[
"SERVER_PROTOCOL"
].
"
"
;
?>
Элемент $_SERVER["REQUEST_METHOD"]
В элемент $_SERVER["REQUEST_METHOD"] помещается метод запроса, который применяется для вызова скрипта: GET или POST.
1 year ago | 9.8K
В программированию, очень часто встречается задача, когда нужно обратиться к другому сайту через HTTP или HTTPS. В этой статье мы рассмотрим простой способ, как с помощью языка программирования PHP выполнить данную задачу.
Для чего обращаться с помощью PHP через HTTP или HTTPS к другому сайту?
Причин может быть несколько, например, на вашем сайте, есть часть функционала, которая отвечает за добавление новых товаров или каталогов фильмов на ваш сайт.
Новые фильмы выходят на экран практически ежедневно и этот процесс лучше автоматизировать, чтобы этим занимался робот, который сделает это бесплатно.
С товарами, ситуация такая же - у вашего интернет-магазина могут быть партнеры, которые захотят разместить на вашем сайте свои товары и с каждой продажи товара, партнеры будут отдавать вам, часть своих доходов. Если у партнера несколько тысяч товаров и база постоянно обновляется, процесс добавления товаров на сайт также необходимо автоматизировать с помощью языка программирования PHP.
Пример обращения к другому сайту с помощью PHP
В этом простом примере, мы будем использовать стандартную функцию PHP под названием file_get_contents().
В ответ от сервера VK, вы увидите следующую информацию:
{ - response: [ - { - id: 210700286, - first_name: "Lindsey", - last_name: "Stirling", - bdate: "21.9.1986" - } - ] }
где, мы получили Имя, Фамилию и дату рождения пользователя с ID 210700286.
Как теперь мы может с помощью PHP получить эту информацию и преобразовать ее в массив, для удобной дальнейшей работы?
С помощью языка программирования PHP и функции file_get_contents(), это сделать очень просто!
$user_id - это переменная, в которую вы записываете ID пользователя VK,
$info - в этой переменной мы сохраняем результат обращения к API сайта VK.COM
Имея массив с этой информацией, вы можете на вашем сайте, отображать интересных вам пользователей, для какой-либо цели, а также с помощью , вы можете красиво оформить вывод данной информации на вашем сайте.
Вывод
Как вы видите, с помощью PHP вы можете очень легко делать запросы к HTTP и HTTPS сайтам и мы рассмотрели лишь одну функцию языка программирования PHP с помощью которой можно получить данные из внешнего сайта.
В следующих статьях, мы рассмотрим еще одну интересную, но более мощную функцию, в которую вы сможете задавать дополнительные параметры, такие как браузер, операционная система и другие, для более изящной работы с внешними сайтами.
Получает объект WP_User, который содержит все данные указанного пользователя.
Данные, возвращаемые функций полностью соответствуют полям таблиц БД: wp_users и wp_usermeta (описание таблиц ).
Это pluggable функция - т.е. её можно заменить из плагина. Это значит, что она будет работать (подключается) только после подключения всех плагинов, а до этого момента функция еще не определена... Поэтому нельзя вызывать эту и зависящие от неё функции прямо из кода плагина. Их нужно вызывать через хук plugins_loaded или позднее, например хук init .
Замена функции (переопределение) - в плагине можно создать функцию с таким же названием, тогда она заменит текущую функцию.
✈ 1 раз = 0.000296с = быстро | 50000 раз = 0.78с = очень быстро | PHP 7.1.2RC1, WP 4.7.2
Хуков нет.
Возвращает
WP_User/false. Объект данных или false, если не удалось найти указанного пользователя.
Использование
get_userdata($userid); $userid(число) (обязательный) ID пользователя, данные которого нужно получить.По умолчанию: нет
Примеры
#1 Как выводить данные из полученного объекта данных
$user_info = get_userdata(1); echo "Имя пользователя: " . $user_info->user_login . "\n"; echo "Уровень доступа: " . $user_info->user_level . "\n"; echo "ID: " . $user_info->ID . "\n"; /* Выведет: Имя пользователя: admin Уровень доступа: 10 ID: 1 */#1.2 Данные в переменную
Еще одни пример, только тут запишем данные сначала в переменные, а затем выведем из на экран:
$user = get_userdata(1); $username = $user->user_login; $first_name = $user->first_name; $last_name = $user->last_name; echo "$first_name $last_name зашел(а) на сайт под логином: $username."; /* Объект $user: WP_User Object( => stdClass Object( => 80 => kogian => $P$BJFHKJfUKyWv1TwЛОВАЕnYU0JGNsq. => kogian => [email protected] => http://example.com/ => 2016-09-01 00:34:42 => => => kogian) => 80 => Array( => 1) => wp_capabilities => Array( => subscriber) => Array( => 1 => 1 => 1) => => 1) */
#2 Методы класса
Получаемый объект с помощью get_userdata() - это экземпляр класса и у него есть методы, которые можно использовать. Иногда это может пригодится. Вот простой пример получения опции пользователя, с помощью метода $user->get() :
$user = get_userdata(1); echo $username = $user->get("user_login");
Список некоторых методов:
- set_role($role) - устанавливает роль пользователя;
get($key) - вернет значение опции;
has_prop($key) - проверяет установлена ли указанная опция;
has_cap($cap) - проверяет имеет ли пользователь указанную возможность или роль;
get_role_caps() - получает все возможности роли пользователя и объединяет их с индивидуальными возможностями пользователя;
add_role($role) - добавляет роль к пользователю;
remove_role($role) - удаляет роль у пользователя;
Заметки
Вот некоторые полезные значения полей таблиц wp_users и wp_usermeta, которые вы можете использовать для получения данных:
- display_name
user_meta
-
user_description
wp_capabilities (массив)
admin_color (тема админ панели. По умолчанию - свежая (fresh))
closedpostboxes_page
- source_domain
Также надо отметит, что с версии 3.2., возвращаемые данные немного изменились: возвращается объект WP_User . Данные в объекте разбиваются на группы: data , caps , roles (раньше данные возвращались в общем списке).
Однако, благодаря "волшебным" (служебным) методам PHP данные можно получить как и прежде, например, сейчас данные хранятся так: get_userdata(1)->data->rich_editing , но получить их можно так: get_userdata(1)->rich_editing , несмотря на то, что var_dump() не покажет эту взаимосвязь.
Код get userdata : wp-includes/pluggable.php WP 5.2.2
$HTTP_SERVER_VARS [удалено](PHP 4 >= 4.1.0, PHP 5, PHP 7)
$_SERVER -- $HTTP_SERVER_VARS [удалено] — Информация о сервере и среде исполнения
Описание
Переменная $_SERVER - это массив, содержащий информацию, такую как заголовки, пути и местоположения скриптов. Записи в этом массиве создаются веб-сервером. Нет гарантии, что каждый веб-сервер предоставит любую из них; сервер может опустить некоторые из них или предоставить другие, не указанные здесь. Тем не менее, многие эти переменные присутствуют в » спецификации CGI/1.1 , так что вы можете их ожидать их реализации и в конкретном веб-сервере.
Переменная $HTTP_SERVER_VARS содержит ту же начальную информацию, но она не суперглобальная . (Заметьте, что $HTTP_SERVER_VARS и $_SERVER являются разными переменными, так что PHP обрабатывает их соответственно). Также учтите, что "длинные массивы" были удалены в версии PHP 5.4.0, поэтому $HTTP_SERVER_VARS больше не существует.
Индексы
Вы можете найти (а можете и не найти) любой из следующих элементов в массиве $_SERVER . Заметьте, что немногие элементы, если вообще такие найдутся, будут доступны (или действительно будут иметь значение), если PHP запущен в командной строке .
" PHP_SELF " Имя файла скрипта, который сейчас выполняется, относительно корня документов. Например, $_SERVER["PHP_SELF"] в скрипте по адресу http://example.com/foo/bar.php будет /foo/bar.php . Константа __FILE__ содержит полный путь и имя файла текущего (то есть подключенного) файла. Если PHP запущен в командной строке, эта переменная содержит имя скрипта, начиная с PHP 4.3.0. Раньше она была недоступна. "argv " Массив аргументов, переданных скрипту. Когда скрипт запущен в командой строке, это дает C-подобный доступ к параметрам командной строки. Когда вызывается через метод GET, этот массив будет содержать строку запроса. "argc " Содержит количество параметров, переданных скрипту (если запуск произведен в командной строке). " GATEWAY_INTERFACE " Содержит используемую сервером версию спецификации CGI; к примеру"CGI/1.1 ". " SERVER_ADDR " IP адрес сервера, на котором выполняется текущий скрипт. " SERVER_NAME " Имя хоста, на котором выполняется текущий скрипт. Если скрипт выполняется на виртуальном хосте, здесь будет содержатся имя, определенное для этого виртуального хоста. " SERVER_SOFTWARE " Строка идентификации сервера, указанная в заголовках, когда происходит ответ на запрос. " SERVER_PROTOCOL " Имя и версия информационного протокола, через который была запрошена страница; к примеру "HTTP/1.0 "; " REQUEST_METHOD " Какой метод был использован для запроса страницы; к примеру "GET ", "HEAD ", "POST ", "PUT ".
" REQUEST_TIME " Временная метка начала запроса. Доступна, начиная с PHP 5.1.0. " REQUEST_TIME_FLOAT " Временная метка начала запроса с точностью до микросекунд. Доступна, начиная с PHP 5.4.0. " QUERY_STRING " Строка запросов, если есть, с помощью которой была получена страница. " DOCUMENT_ROOT " Директория корня документов, в которой выполняется текущий скрипт, в точности та, которая указана в конфигурационном файле сервера. " HTTP_ACCEPT " Содержимое заголовка Accept: из текущего запроса, если он есть. " HTTP_ACCEPT_CHARSET " Содержимое заголовка Accept-Charset: из текущего запроса, если он есть. Например: "iso-8859-1,*,utf-8 ". " HTTP_ACCEPT_ENCODING " Содержимое заголовка Accept-Encoding: gzip ". " HTTP_ACCEPT_LANGUAGE " Содержимое заголовка Accept-Language: из текущего запроса, если он есть. Например: "en ". " HTTP_CONNECTION " Содержимое заголовка Connection: из текущего запроса, если он есть. Например: "Keep-Alive ". " HTTP_HOST " Содержимое заголовка Host: из текущего запроса, если он есть. " HTTP_REFERER " Адрес страницы (если есть), которая привела браузер пользователя на эту страницу. Этот заголовок устанавливается веб-браузером пользователя. Не все браузеры устанавливают его и некоторые в качестве дополнительной возможности позволяют изменять содержимое заголовка HTTP_REFERER . Одним словом, в самом деле ему нельзя доверять. " HTTP_USER_AGENT " Содержимое заголовка User-Agent: из текущего запроса, если он есть. Эта строка содержит обозначение браузера, которым пользователь запросил данную страницу. Типичным примером является строка: Mozilla/4.5 (X11; U; Linux 2.2.9 i586) . Среди прочего, вы можете использовать это значение с функцией get_browser() чтобы адаптировать вывод вашей страницы к возможностям браузера пользователя " HTTPS " Принимает непустое значение, если запрос был произведен через протокол HTTPS.Замечание :
PHP скрипт завершается после посылки заголовков (то есть после того, как осуществляет любой вывод без буферизации вывода), если запрос был осуществлен методом HEAD .
" REMOTE_ADDR " IP-адрес, с которого пользователь просматривает текущую страницу. " REMOTE_HOST " Удаленный хост, с которого пользователь просматривает текущую страницу. Обратный просмотр DNS базируется на значении переменной REMOTE_ADDR .Замечание : Обратите внимание, что при использовании ISAPI с IIS значение будет off , если запрос не был произведен через протокол HTTPS.
" REMOTE_PORT " Порт на удаленной машине, который используется для связи с веб-сервером. " REMOTE_USER " Аутентифицированный пользователь. " REDIRECT_REMOTE_USER " Аутентифицированный пользователь, если запрос был перенаправлен изнутри. " SCRIPT_FILENAME "Замечание : Ваш веб-сервер должен быть настроен, чтобы создавать эту переменную. Для примера, в Apache вам необходимо присутствие директивы HostnameLookups On в файле httpd.conf , чтобы эта переменная создавалась. См. также gethostbyaddr() .
Абсолютный путь к скрипту, который в данный момент исполняется.
" SERVER_ADMIN " Эта переменная получает свое значение (для Apache) из директивы конфигурационного файла сервера. Если скрипт запущен на виртуальном хосте, это будет значение, определенное для данного виртуального хоста. " SERVER_PORT " Порт на компьютере сервера, используемый веб-сервером для соединения. Для установок по умолчанию, значение будет "80 "; используя SLL, например, это значение будет таким, какое сконфигурировано для соединений безопасного HTTP.Замечание :
Если скрипт запускается в командной строке (CLI), используя относительный путь, такой как file.php или../file.php , переменная $_SERVER["SCRIPT_FILENAME"] будет содержать относительный путь, указанный пользователем.
" SERVER_SIGNATURE " Строка, содержащая версию сервера и имя виртуального хоста, которые добавляются к генерируемым сервером страницам, если включено. " PATH_TRANSLATED " Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping.Замечание : Чтобы получить физический (реальный) порт в Apache 2, необходимо установить UseCanonicalName = On и UseCanonicalPhysicalPort = On , иначе это значение может быть подменено и не вернуть реальной значение физического порта. Полагаться на это значение небезопасно в контексте приложений, требующих усиленной безопасности.
" SCRIPT_NAME " Содержит путь, к текущему исполняемому скрипту. Это полезно для страниц, которые должны указывать на самих себя. Константа __FILE__ содержит полный путь и имя текущего (т.е. включаемого) файла. " REQUEST_URI " URI, который был передан для того, чтобы получить доступ к этой странице. Например, "/index.html ". " PHP_AUTH_DIGEST " При выполнении HTTP Digest аутентификации, этой переменной присваивается заголовок "Authorization", который присылается клиентом (его необходимо потом использовать для соответствующей валидации). " PHP_AUTH_USER " Когда выполняется HTTP-аутентификация, этой переменной присваивается имя пользователя, предоставленное пользователем. " PHP_AUTH_PW " Когда выполняется HTTP-аутентификация, этой переменной присваивается пароль, предоставленный пользователем. " AUTH_TYPE " Когда выполняется HTTP-аутентификация, этой переменной присваивается тип аутентификации, который используется. " PATH_INFO " Содержит любой предоставленный пользователем путь, содержащийся после имени скрипта, но до строки запроса, если доступно. Например, если текущий скрипт запрошен по URL http://www.example.com/php/path_info.php/some/stuff?foo=bar , то переменная $_SERVER["PATH_INFO"] будет содержать /some/stuff ?>Замечание : Начиная с PHP 4.3.2, переменная PATH_TRANSLATED больше не устанавливается неявно в Apache 2 SAPI , по сравнению с Apache версии 1, где она устанавливается в то же самое значение, что и переменная SCRIPT_FILENAME , когда она не используется Apache. Это изменение было сделано для соответствия спецификации CGI , где переменная PATH_TRANSLATED должна существовать только тогда, когда PATH_INFO определена. Пользователи Apache 2 могут использовать директиву AcceptPathInfo = On в конфигурационном файле httpd.conf для задания переменной PATH_INFO .
Результатом выполнения данного примера будет что-то подобное.
